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1. INTRODUCTION 


SOCRATES? has built the foundations to introduce and deploy the next step in traffic 
management. We call this concept ‘interactive traffic management’, meaning a close 
cooperation and collaboration between different public and private partners in the traffic 
management ecosystem. As part of this concept, traffic management information is 
exchanged and translated into intelligent decisions and behaviour, with the overall goal of 
enhancing the quality, safety and efficiency of traffic for road users. The concept is 
expected to lead to more business opportunities for the private partners and more cost- 
effective traffic management for the public authorities. 
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Figure 1. Concept of interactive traffic management 


In more concrete terms, SOCRATES2° developed a cooperation framework and 
demonstrated pilot deployments of new measures and services for the interactive traffic 
management concept. 


This report consolidates the outcomes of the entire project, draws conclusions and 
provides recommendations and guidelines for deploying the concept of interactive traffic 
management on a wider scale. 


Furthermore, the report proposes follow-up activities to evolve and roll out the interactive 
traffic management concept after conclusion of the project, eventually leading to a 
European-wide deployment. 


This way, the Consolidation Report deals with two perspectives: first, looking back at 
SOCRATES? experiences, and then looking forward to a Post- SOCRATES?” era, to allow 
potential follow-up activities take on the experience and guidance made in our project. 
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Figure 2. Two perspectives of the Consolidation Report 


The report is intended for stakeholders, such as public administrations, service providers 
and car manufacturers, and relevant European initiatives involving emerging intelligent 
transportation systems and advanced traffic management schemes. The conclusions in this 
report can support these actors in making decisions about the deployment of new traffic 
management measures and services, as initiated in SOCRATES?, 


This report is part of the final dissemination activities of the SOCRATES”? project: 

e The Consolidation Report (the current report) represents a consortium perspective 
on basic components and overarching issues of the SOCRATES? project, as well as its 
underlying concept of interactive traffic management. 

e The Evaluation Report! is an evidence-based perspective on the outcomes of the 
Socrates*° project. 

e The digital magazine? presents a bird's view of the SOCRATES?” story. 


The current Consolidation Report is organised as follows: 

e Section 2 presents basic elaborations on aspects that facilitate the concept of interactive 
traffic management. This includes mainly the cooperation framework, common formats 
for digital data exchange, and means for communicating with road users. 

e Section 3 gives recommendations for concrete implementations of the concept, based 
on learnings from the project deployments. 

e Section 4 compiles lessons learned about selected enablers and bottlenecks, with the 
goal to enable the concept on a wider scale, again based on project experiences. 

e Section 5 identifies arrangements required for further deploying the concept after 
conclusion of the project, put together as a follow-up plan. 


Whereas this report is considered a central document about all aspects of SOCRATES*®, some 
further, specific resources provide more insights on selected aspects. These other resources 
are cited throughout the report, and can be downloaded from the SOCRATES?® website. 





1 See the SOCRATES?” Final Evaluation report 
2 See the SOCRATES?” digital magazine 
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2.1 Vision and conceptualisation 


The SOCRATES?” interactive traffic management concept aims to enable a new approach to 
network-based traffic management. It presents new means and methods to steer transport 
networks. The approach integrates control mechanisms in the responsibilities of both road 
authorities and service providers that increase the efficiency and consistency of 
components of individual traffic management systems. The approach is based on the TM?° 
initiative? and is shown in the next figure. 
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Figure 3. TM2.0 concept 


Before concretising and deploying the above concept, the project partners elaborated 

a shared, higher-level vision for the long-term development in traffic management. This 
vision considers technological advancements affecting the transportation system, such as 
new communication channels and enhanced connectivity, as well as the individual needs of 
stakeholders involved in the transportation system, namely road users, public actors and 
private actors in traffic management. 


The vision looks at four perspectives: technology, community, customer and cooperation, 
for which slogans, main ideas and principles were defined (see the next figure). 

This shared vision identified the individual and joint motivations, interests and 
expectations. And assembling the shared vision together helped build trust and a common 
language between the partners. This was the basis for exploring the possibilities of 
cooperation. 





3 ERTICO Traffic Management 2.0, See: https://tm20.org/ 
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Figure 4. The four elements of SOCRATES2.0 and their slogans 
The four elements of the vision are explained as follows: 


CUSTOMER 

Making the customer an active part of interactive traffic management: let them provide 
and consider feedback. But also let them provide specific information, guidelines and 
motivation on common traffic strategies for their own journey. The customer should be 
convinced of the benefit of the offered service. However, customers will not actively be 
involved in the development itself; this will be achieved via the service providers. 


COMMUNITY 
People as a group can have a certain impact on society or a city with their travel behaviour. 
By supporting communities during their journeys, the alliance can influence that impact. 


TECHNOLOGY 

Technology serves as a means to support the individual user, society, communities and the 
alliance. The project aims to combine technologies in a smart, user-centred way (balanced 
route optimisation, gamification, predictions). 


COOPERATION 
Make the cooperation fit impact-driven business models. A key aspect is to define 
collaboration KPIs: how to measure who contributed what to the common goals. 


This vision forms the basis for the entire project elaboration, and is detailed in a separate 
report’. 





4 See the report “Shared vison, framework and bottlenecks in the SOCRATES?° project” 
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This strategic perspective was translated into a more tactical perspective, proposing 
specific solutions, which were later trialled in real-world SOCRATES?” pilots. These solutions 
mostly involve harmonised elements that enable the interactive traffic management 
concept to be deployed on a European-wide scale (after validation and further roll-out). 
These harmonised elements include functional, organisational and technical aspects, and 
are detailed in the next sections. 





2.2 Cooperation framework 


A basic building block for the concept of interactive traffic management, as elaborated and 
demonstrated in SOCRATES?, is a cooperation framework. This represents a functional 
and organisational architecture, allowing a smooth and efficient cooperation between the 
participating stakeholders, namely road users, traffic management centres, the automotive 
industry and data- and service providers. 


All SOCRATES?” partners believe that by cooperating, new business opportunities can be 
developed for private partners, more cost-effective traffic management can be achieved 
for public authorities and most importantly better services can be provided for road users 
and communities. The SOCRATES?° partners call this a win-win-win for all stakeholders. The 
goal of SOCRATES?’ is, to test if this added value can be achieved by a closer cooperation 
and find out how this can lead to sustainable business cases for all stakeholders. 


To make such win-win-win happen, a cooperation framework is introduced in the centre of 
the SOCRATES29 concept, as indicated by the next figure. 
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Figure 5. SOCRATES2.0 cooperation framework 


The SOCRATES? cooperation framework has elaborated three cooperation models. 

These models describe the type and intensity of cooperative tasks among the participating 
partners. Next, we will take a closer look at these cooperation models, describe the 
differences and elaborate on the benefits and challenges for each model. 


Furthermore, we take a look at the ‘roles’ needed to conduct cooperation in traffic 
management. For each cooperation model, a pre-selection of roles should be considered. 
Besides traditional roles like data- and service providers, four new roles were introduced by 
SOCRATES2%, These new roles relate to intermediary roles, and are an integral part of the 
SOCRATES? cooperation framework, as indicated by the figure above. 
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Figure 6. SOCRATES2.0 cooperation models and intermediaries 


The SOCRATES?” partners created a cooperation framework that defines three ways 

of working together - called cooperation models - and identifies four new roles - the 
intermediary roles - that are necessary to make the cooperation work. The figure above 
indicates the three cooperation models (as vertical arrows), and the corresponding 
intermediary roles (as red boxes). The main distinction between the cooperation models is 
the level of communality. The communality determines how close partners work together. In 
other words, partners can choose to just ‘wave’, ‘shake hands’ or ‘hug’ each other. 


The first cooperation model is comprised of agreements for sharing public and private traffic 
data, based on agreed data exchange formats (Exchanged Data). The second model brings 
the cooperation partners a step closer to each other. The partners create a Shared View for 
the road network (e.g. common situational picture). The Shared View is based on Exchanged 
Data. Partners use the Shared View independently from each other. The most elaborate 

level of cooperation arises when, based on Exchanged Data and a Shared View, partners 
develop and implement coordinated actions and services towards the travellers (Coordinated 
Approach). 


Depending on the envisaged service or use case, the level of cooperation can vary. For a 
danger warning service, the Exchanged Data cooperation could be suitable. Optimising 
traffic flow over an entire network on the other hand may require a Coordinated Approach. 
So, the selection of the use case mainly determines the type of cooperation model. On the 
other hand, the complexity of creating and running a cooperation is mainly determined by 
the use case. 


This table gives an overview of some of the characteristics of the three cooperation models. 
It is noted that these cooperation models can apply to any of the layers of traffic 


management: operational, tactical, and strategic, according to common definitions®. 


Table 1. Characteristics of the three SOCRATES2.0 cooperation models 


Main activity Sharing data Creating (and Coordinating actions 
using) a common 
situational picture 


| Whatis common? | is common? Exchange format Situational picture Approach strategy 

Data Standardisation of Enrichment of data Meaningful and 
e N EE maa EE 

| Typical Scalable | Scalable European | | National | Regional = 


SOCRATES? Use cases Speed and lane Roadworks and Optimising network 
information environmental flow 
zones 








5 Spoelstra, J., van Waes, F., Mann, M., Kontantinopoulou, L., Dr. Tzanidaki, J., 2017. Exchanging Traffic Management Plans data 
between Traffic Management Centres and Service Providers in Traffic Management 2.0. 12th ITS European Congress, June 2017, 
Paper no. TP0809. 
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Exchanged Data cooperation model 


This model of cooperation is about exchanging data on a voluntary 
base using an agreed standard protocol. There are multiple 
Furopean standards and variations for the same purposes. Agreeing 

on one standard and using it in an aligned way is the challenge. Pe 


1. Exchange data 


This is the entry model. It is a building block for the two higher ACTUAU SPEED 
cooperation models. But it is also suitable for services aiming at AND LANE ADVICE 


spreading information without the need for further enrichment of 
the data or coordinated actions. This is applicable for speed and Inform each orner ; 
lane information as was developed in the SOCRATES?° Antwerp ie ee ane 


pilot site. The main focus is sharing information in order to obtain 
a maximum information coverage for the end users. Each party 
continues to use its own services to communicate with the end user. 





The benefits of this model are: 
e improved information coverage for public and private parties (back-end). 
e improved service guality for end users (front-end). 


The challenges of this model are: 

e Agreeing on which standard to use for multiple partners. For some applications, multiple 
standards are available. 

e Agreeing on how to use that standard and to keep the scope for the use case 
manageable (less is more). 

e Partners participating in this cooperation model need to make certain efforts to make 
their data available and accessible. 


Exchanged Data is a basic model for cooperative traffic management. It promises relatively 
low technical hurdles to start with cooperation. It can already add value to the system, 
especially for the end users, as it improves the availability of relevant data. In many cases it 
requires low investments, as most of the required infrastructure and interfaces will be already 
available and only minor adjustments will be required (adaptation to harmonised standard). 
The aspect of identifying the appropriate business model remains a challenge, as evenina 
data-driven society few models are available for data sharing in a money-driven economy. 


Shared View cooperation model 


This model of cooperation is based on the cooperation model 
Exchanged Data, but introduces the concept of a common 
situational picture. This means all involved parties, public and 
private, operate on the same consolidated information. 


2. Shared view 


This cooperation model is suitable for use cases in which sharing 


data to enable a ‘common situational picture’ will add value to the 
ENVIRONMENTAL ZONES 


system. This is applicable for environmental zones and roadworks AND ROAD WORKS 


information as was developed in the various SOCRATES?’ pilot sites. 


Develop common view 
of agreed information 





In this case, several parties have similar, sometimes complementing or overlapping 
information, but instead of just exchanging the content the value is in cleaning, completing, 
merging, aggregating and distributing the content and thus allowing all parties to operate on 
the identical ground truth. This approach will eliminate the risk of contradicting/unaligned 
information provision to the end user which may happen in the Exchanged Data cooperation 
model. Still each party continues to use its own services to communicate with the end user. 


The Shared View cooperation model requires an additional, intermediary role to achieve 
the common situational picture, the so-called Network Monitor. In a nutshell the Network 
Monitor collects data from the various sources, executes quality checks, merges the 
content and delivers the consolidated content through a standardised interface. More 
details can be found in the section on roles below. 


The benefits of this model are: 

e improved information coverage for public and private parties (back-end). 

e improved service quality for end users (front-end). 

e trusted entity (intermediary) operating the Network Monitors enables data sharing even 
between competing parties. 

e same foundation for taking actions for all parties. 

e alignment of information provided to the end users. 


The challenges of this model are: 

e identification of the appropriate standard for (enriched) information exchange. 

e harmonised (read and write) usage of the identified standard. 

e scaling of standardisation aspects from regional to national and European level. 

e agreeing to appropriate business model for sharing data. 

e agreeing to terms and conditions allowing not only the sharing of data, but also the 
modification and merging. 

e identifying commonly accepted trusted parties. 

e establishing trust between parties involved. 
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The Shared View cooperation model is an improved model for cooperative traffic management 
with limited technical hurdles for interacting with each other. The main benefit for the overall 
system and the end users is, that all actions are based on the same operational picture and no 
contradicting information should be provided to the travellers (just informing’). 


The investments to make this cooperation model happen are expected to be higher 

than for the Exchanged Data cooperation model as the initial costs for implementing the 
Network Monitor and continuous costs for operating the Network Monitor will need to be 
covered. Related to that, but also considering the enablers for data sharing, identification 
of the appropriate business model is key. 


Coordinated Approach cooperation model 


This model of cooperation is far more ambitious than the previous 
two cooperation models. It is not only about achieving a common 
ground truth, but agreeing on coordinated actions amongst all 
parties involved, public and private, to achieve a set of previously 
agreed common goals. 


3. Coordinated 
approach 


This model is suitable for use cases in which a set of commonly 
identified and agreed goals can only be achieved by coordinated 
actions of all parties. 


SMART ROUTE ADVICE 


Coordinate 
end user services 
This model is suitable in cases where achieving common goals in 


traffic management require coordinated actions of the partners 
involved. This can be the case especially in routing services, where 
the sum of all individual optimal routes does not (necessarily) 
result in the collective optimum. In order to achieve that collective 
optimum as a common goal, a Coordinated Approach is needed. 
Partners first need to agree upon this common goal (e.g. an optimal 
distribution of traffic over the network). Subsequently they need to 
obtain a common picture of the actual traffic state and the desired 
action to be taken. As some of these actions might be suboptimal 
on an individual base (e.g. leading to a longer individual route) a 
form of compensation might be needed in order to seduce the end 
user to comply with this action. 





Service providers still have the flexibility to identify the right and acceptable recommendations 
to their users while not only considering but also contributing to the common. This ambitious 
cooperation model was chosen for the Optimising Network Traffic Flow use case and was 
implemented in the SOCRATES?” pilot sites in Amsterdam, Antwerp and Copenhagen. In the 
Coordinated Approach cooperation model, end users and travellers become an important 
role as well, as the more actively they participate, the more likely they are to follow advice and 
change their behaviour, thus resulting in a better impact. An appropriate incentive and reward 
model may stimulate the contribution of end users. 


The Coordinated Approach cooperation model reguires several additional intermediary 
roles to operate a system of coordinated actions. One of the roles is the Network Monitor, 
already introduced and needed for the Shared View. 


The other reguired roles are: 


e the Strategy Table - aligns public and private goals, translates commonly agreed goals 
into measurable KPls and determines available services. 

e the Network Manager - determines the problem state based on the actual and desired 
situation, determines a solution based on available services, sends so-called service 
requests (coordinated actions) to public (road authorities) and private (navigation) 
service providers. 

e the Assessor - assesses the contribution of all service providers (public and private) to 
the commonly achieved KPIs. 


More details can be found in the section on roles below. 
The benefits of the Coordinated Approach are: 


e improved information coverage for public and private parties (back-end). 

e improved service quality for end users (front-end). 

e enables the identification of common goals, set of agreed services (or high-level actions) 
per partner and KPI framework as common framework for operational success. 

e trusted partner enables data sharing even between competing parties. 

e trusted partner enables operation of coordinated actions. 

e trusted partner allows neutral assessment of performance indicators per partner as 
basis for impact-driven business model. 

e the coordinated actions enable “true” interactive and cooperative traffic management to 
improve network efficiency. 


The challenges of this model are: 


e identification of the appropriate standard for information exchange. 

e harmonised (read and write) usage of the identified standard. 

e scaling of standardisation aspects from regional to national and European level. 

e agreeing to appropriate business model for trusted roles. 

e agreeing to terms and conditions allowing not only the sharing of data, but also the 
modification and merging. 

e identifying commonly accepted trusted partners for intermediary roles. 

e establishing trust between parties involved. 

e appropriate governance and business model. 

e appropriate tendering process. 

e establishing mechanisms to motivate road users to behave according to common goals, 
even when they experience suboptimal situations, such as longer routes. 


The Coordinated Approach cooperation model is a blueprint for interactive and cooperative 
traffic management with organisational and technical challenges. The main benefit for the 
overall system and the end users is that commonly agreed and coordinated actions are 

the success factor for an improved network management while considering the benefits to 
individual travellers at the same time. 


The upfront investments to make Coordinated Approach cooperation model happen 

are higher as for the former two cooperation models, as there are additional costs for 
implementing and operating the new intermediary roles. Operating new (impact-driven) 
business models can be an additional short-term cost factor as well. However, in the long 
run, additional societal benefits are expected. 


Roles 





The main building blocks for the cooperation models are the ‘roles’. A role is defined as 

a set of tasks (or functions) that need to be carried out together with a responsibility to 
create added value for the cooperation as a whole. A role could be performed by one or 
more partners, as long as the responsibilities within the role are clear. For example, partner 
A is responsible for the content and partner B is responsible for the technology within 

one role. The number of tasks assigned to a role makes the role more or less complicated 
to perform. Also, one partner can perform multiple roles. This makes the SOCRATES?° 
Framework flexible and adaptable for regional situations. 


To enable a public-private cooperation for interactive traffic management (e.g. the TM?° 
concept) four new intermediary roles were introduced: Network Monitor, Network 
Manager, Strategy Table and the Assessor role. They work closely together with the more 
traditional roles like data provider, service provider and traffic management centre (TMC). 


We define an ‘intermediary’ as a dedicated role between the traditional public and private 
sector that enables central and crucial functions of the interactive traffic management 
concept. The intermediary role is performed by a trusted public or private organisation; 
or a combination. We realise that in many modern TMCs, some such roles are already 
embedded, for example a Network Manager may be part of the TMC's unit to manage 
traffic by its own means via CCTV and VMS. However, we prefer to isolate such tasks as 
explicit roles, because we think an explicit role definition makes it easier to implement 
advanced and innovative tasks of such roles, for example by giving those tasks to a 
dedicated, maybe more agile partner, instead of trying to integrate them into legacy 
systems of say a TMC. 


The main interactions between the roles are visualised in the slide below. 
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Figure 7. Interactions between the intermediary roles 
In logic order the roles are: 


Data provider 

One or more data providers are responsible for the delivery of data. Both public and private 
partners can be data providers. We recommend exploiting any existing and emerging data 
sources for the goals of interactive traffic management, such as static road maps, roadside 
detectors, crowd- and fleet-based traffic data, and, in the future, data from cooperative 
systems (C-ITS) 


Task 1: Data collection 

Data provided by public partners typically include induction loop or other road sensor data 
that provide information on traffic conditions (volumes, speeds, vehicle categorisation). 
Public sources also include data on road works, incidents, dynamic speed limits and dynamic 
lane openings/closures. Information on air quality, the status of environmental zones and the 
status of traffic management measures can be shared as well. Private data providers typically 
share GPS based floating car data (speeds and travel times) and crowd sourced data on 
incidents, roadworks, lane openings/closures, etc., as reported by their travellers. 


Task 2: Alignment and Data distribution 

Public and private data providers send their data in real-time to the Network Monitor. 
They make agreements with the Network Monitor on how to transmit these data. APIs are 
set up and corresponding specifications are provided to the Network Monitor explaining 
the used protocols, the temporal and spatial referencing systems, etc. Data providers and 
the Network Monitor make agreements on data transmission specifics including latency, 
data quality standards and data protection regulations. 
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Network Monitor (new intermediary role) 

When partners decide to cooperate by exchanging their data and based on that create 

a shared view, the Network Monitor needs to be implemented. The Network Monitor 

is especially useful if multiple data providers are available and a high guality common 
view is needed. To this end, the Network Monitor collects data from road authorities and 
private data providers and determines the shared view for a predefined use case related 
to network and indicators. In this process the Network Monitor can perform data handling 
services such as quality assessment, data completion and fusion of different public- 
private sources according to use case and business requirements. The Network Monitor 
distributes the network common state to other intermediary roles and other agreed 
parties. Partners then can base their own services on a higher-quality shared view. 


Task 1: Data collection 

The Network Monitor collects the data from one or more data providers. Depending on the 
use case, several input data sources are used. Traffic information sources consist of regular 
induction loop data (volume, speed), floating car data (travel times), incidents, road closures 
and road works. Other data sources have also been used and developed in SOCRATES2°. In 
Copenhagen, data sources about the number of cyclists and air quality were used, and in 
Amsterdam information about the status of environmental zones was collected and a data 
feed was developed with traffic management measures activated by the TMCs. 


Task 2: Data processing 

In this task the Network Monitor performs data handling services such as quality assessment, 
data completion and fusion of different public-private sources. In most SOCRATES? use cases, 
it is first determined for which roads or for which road network the service will be performed. 
The challenge for the Network Monitor is to ensure that the information from the different 
sources is linked to the correct road segments. During the use cases where new networks 
were needed, it turned out that a lot of time was spent on determining the network and the 
map matching of the data. If done correctly, a common current (and if possible predicted) state 
is determined. Possible extra tasks are mapping, standardising, data fusion, completion and 
prediction. The Network Monitor distributes or shares the ‘state of the network’. 


Task 3: Data distribution 

After collecting and processing the data, the data is published publicly or sent specifically 
to the Network Manager. This depends on the chosen cooperation model. This data output 
stream is neutral and factual. 


Agreements about the data exchange are important here: for example the format to be 
used, the frequency of delivery (e.g. on a minute basis) and the method of delivery (push by 
Network Monitor or pull by customer). The connections and data points are set up on the 
basis of these agreements. For the data format, there was a separate agreement between 
the SOCRATES?” parties that laid down which data formats were used for which purpose 
(TMex). The DATEX II format was frequently used here. 
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Network Manager (new intermediary role) 

The Network Manager is an important role needed for the Coordinated Approach cooperation 
model. The Network Manager has the strategic goals and KPIs from the Strategy Table as 
input. These strategic goals are translated to tactical KPIs and used to determine the network 
problem state. 


Task 1: Determination of problem state 

The Network Monitor provides the Network Manager with traffic data (e.g. volumes, speed 
and active services) possibly supplemented by other data like emissions. Using predicted 
traffic state data is useful to have, but not crucial. These traffic states are then compared 

to the KPIs derived from the Strategy Table. Now the Network Manager can determine 

the problem state for each link of the entire network; for example, a level of service (LOS) 
according to the Highway Capacity Manual (HCM2016). The LOS could be ‘A’ to 'F, with ‘A’ 
being low density traffic and free flow speeds and 'F being high density, low speed traffic or 
forced flow. A problem on a link occurs if the current state and predicted state fall below a 
certain level, causing a trigger reaction. 


Task 2: Selecting services to alleviate the problem 

The Network Manager has a set of services which are realised by the TMCs and service 
providers. These services are stored in a ‘toolbox’. Each type of service has its own data 
attributes (unique name, ID, trigger level, effect area, location, etc.). Triggered by a KPI like 
decreasing LOS, a service is selected (or nominated) to be activated with the goal to reach 

a better LOS. The Network Manager takes into account the effect (e.g. change in volume) of 
the selected service(s). In addition, already activated services are taken into consideration 
since services can have contrary effects. A service can also support other services. This 
means that services can be used on links where there is no immediate traffic problem. The 
services act like intelligent agents searching for opportunities to improve the situation. 


Volume to Capacity Ratio S =sf/(1+a(v/c)”) 
0.0 to 0.2 0.2004 0400.7 07to08 0.8to1.0 >1.0 


Speed 





Level of Service 
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All these choices and conflicts are taken into account when the Network Manager selects 
services. This can be done through a conflict resolution matrix where priority is given to 
certain types of services. This can result in solutions where, for example, three supporting 
services are activated to alleviate the traffic problem on one link. The Network Manager 
does not differentiate between services of TMCs and private service providers when 
deciding which service to activate but looks at the impact a service can generate. 


Task 3: Service requesting 

The process of requesting another partner to conduct a particular service is called a 
‘Service Request’ (SR). SRs to TMCs are sent in an agreed exchange format (e.g. DVM 
Exchange: this is a Dutch standard for requesting services between TMCs). SRs to service 
providers can be sent in a DATEX II format; a European standard for traffic related data 
exchange. In SOCRATES? most SRs were ‘advisory’ messages. It is important to allow some 
operational freedom, unless services concern legally-binding regulations, such as speed 
limits. Public services are ‘increase outflow’ (e.g. adapting traffic light green times), ‘reduce 
inflow’ (e.g. ramp metering) and ‘reroute’ (e.g. VMS). Private services are typically but not 
exclusively done through the routing algorithm of a navigation system. These services 
have the benefit of targeting individual road users. In Socrates2.0, private services are 
mainly based on the ‘avoid’-SR and ‘reroute’ SRs. An avoid SR means that services should be 
activated to avoid a specific network link, while a reroute SR means that services should be 
activated to rerouted traffic following a specific route (made up of several network links). 
Once a service is requested by the Network Manager, the TMC is requested to deploy their 
service. The private service providers are simultaneously requested to reroute their users 
based on the same principles as the public service providers and in this way support the 
goals of the public service provider. 


Task 4: Short cycle evaluation 

A short cycle evaluation can be accomplished by setting a team consisting of all participants 
that meet regularly to discuss issues regarding development and operational use. They use 
analytic tools to analyse algorithms, traffic data and the quality of the requested services. 
This leads to gradual improvement of the Network Manager. 


Traffic Management Centre (TMC) 

A TMC is the operational organisation of the road authority for traffic management. In 
general responsibilities are managing incidents, objects, roadworks and/or congestion. 
However, managing traffic on a big scale network is rather new. TMCs use viable 
message signs, traffic light controllers, cameras, etc. to manage traffic. In the SOCRATES?° 
Amsterdam pilot, TMCs received SRs for the purpose of network optimisation. 
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Task 1: Preparation and quality validation 









Prior to the operational phase, traffic engineers 
need to translate the (pre-agreed tactical) SRs to 
concrete measures that can be activated in the 
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Task 2: Operator assessment and activation 
During the operational phase, the operators receive 
SRs. They can either acknowledge, decline or snooze 
a request. When acknowledged, accompanying 
existing services (a selection of one or more traffic 
management measures) are activated (e.g. the 
display of a message on a dynamic panel, adjustment 
of green times of traffic lights, and the activation of ramp metering). An operator assessment 
can be fully or partially automated if the quality is good enough. 








Task 3: Logging 

For evaluation purposes all actions and special circumstances are logged by systems 

and operators. This information is then collected and analysed by the TMC engineers and 
frequently forwarded to the Assessor for further analyses of impact and value. 


Service provider 

The service provider receives the SRs in its backend system and will assess these SRs to 
determine whether or not to distribute these to its individual service users. The service 
provider may try to encourage desired behaviour by its users and may evaluate this. 
The service provider provides input to the Assessor. 


Task 1: Receive SR 

A service provider receives an incoming SR that is sent out by the Network Manager. 

The SR has a predefined structure following a protocol standard (e.g. DATEX Il or DVM-X). 
Depending on the use case, the frequency of incoming SRs may vary from a few SRs per 
second to a few per hour (or even per day or per week or per month). 


Task 2: Assess SR 

An incoming SR will be (temporarily) stored in the backend system of a service provider. 
The service provider will assess the SR to determine what to do with it. This assessment 
may differ per use case and also per service provider and is in function of the agreed-upon 
cooperation model. Some assessment criteria may be: 
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Compare SR with the previous/current/upcoming advice of the service provider's 


own system 


Take into account the number of (almost) identical SRs that have been received 
Take into account the number of (almost identical) advice messages that the service 


provider has sent out to its users 
Assess foreseen impact of SR and balance cost and benefit of involved incentive 


and reward 


Not all service providers will use all of these assessment criteria. 
The outcome of the assessment will determine whether or not to use the SR. 


Task 3: Distribute to user 
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An SR that has been assessed and determined to be used will 
be distributed to the users of the service provider's service. 
The service provider will transform the SR to match its own 
communication service channel. This communication channel 


could be for example: 


e Routing advice in a navigation system 
e A pop-up message in a navigation system 
e A message and a hyperlink to a navigation application in a 


text message 


Above formats are examples; more formats and combinations 


are possible. 


Task 4: Encourage and evaluate user behaviour 

If the aim (of road authorities, service providers and/or other 
initiators) is to have a fast, safe and green impact on traffic, 
then they need to establish a marked effect on or at least 








influence the behaviour of individual traffic participants. 





The service provider has the possibility to encourage desired behaviour and also to 


evaluate the actual behaviour. 


The service provider can encourage behaviour by means of: 


e Awareness campaigns 


e Indirect incentives 


e Direct/financial incentives 


The service provider can evaluate user behaviour by means of: 


e Feedback from users 


e System data 
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Task 5: Provide input to the Assessor 

Service providers provide input to the Assessor. This input can consist of system data and/ 
or elaborated evaluation data. The input is provided following a predefined format and 
freguency. 


Assessor (new intermediary role) 

The Assessor supports the Coordinated Approach cooperation model by providing the 
Strategy Table (and the Network Manager) with insights on the service performance based 
on data and information individually collected by all partners involved in the delivery of 
the service. The Assessor translates them into the predefined goals and KPls. The partners 
seated at the Strategy Table use the validated insights from the Assessor for data-driven 
strategic decisions on how to improve the jointly developed services. 


Task 1: Collection of data and information 

The Assessor collects a vast amount of data from all the roles involved in the delivery of 
the smart routing service. It “reads” the Network Monitor data feed on the current and 
predicted state. It also collects the periodical log on activated measures from Network 
Manager and the SRs sent out to each of the service providers and TMCs. And it collects the 
self-assessment report from TMCs and service providers based on the pre-agreed Waterfall 
report where several data indicators provide information on the reception, usage and 
implementation of the SRs information in each of their end-user services, including: 


e aggregated volumes of users (travellers) which received (route) advice from an SR; 

e how many (likely) changed their routes accordingly or not; 

e reasoning for (non)acceptance of SR or not providing ‘requested’ advice to users; 

e context information (e.g. TMC logging) from their perspective on the network conditions 
during an SR. 


Task 2: Validation of collected data and information 

The collected reports contain data and information on the technical and functional 
performance of each of the systems and services. The Assessor reviews the data with 
plausibility checks which are also used for operational reports to the Network Manager and 
validation dialogues with service providers. For example: indications on the uptime of each 
of the services, completeness of data or information, volumes of data exchange or even 
questionable data values or SRs. 


Task 3: Translation to KPI framework and reporting 

The Assessor translates the validated insights to the predefined KPI framework established 
by all the partners sitting at the Strategy Table. This information is used to regularly 
establish the impact of each partner in achieving the goals of the total ecosystem. 

The results are used to assess if adjustments of the KPIs and/or toolbox are necessary 

and in how far the cooperation of the participating partners is successful. 
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The Assessor plays an expert independent role when evaluating both technological 
and commercial aspects of the cooperation. It supports the management of the SLA 
agreements and ensures that the cooperation principles are honoured. Because of its 
independent unbiased role, the Assessor can act as a trusted third party to collect and 
interpret information that is preferably not shared with the whole consortium. Only 
the agreed-upon information is shared with all stakeholders. 


Strategy Table (new intermediary role) 
The Strategy Table develops the joint strategy of all participating parties. The collaborative 
model of the Coordinated Approach revolves around jointly managing strategic KPIs. 


Task 1: Alignment of goals 

The Strategy Table is responsible for strategic alignment of public and private goals 

into commonly agreed goals. These goals are implemented by the Network Manager to 
determine the problem state and possible measures. To this end, KPls are established for 
the entire network under control and translated into KPls like LOS of the network sections 
at hand and stored. To achieve these strategic KPls, the intermediary role of the Network 
Manager translates them into tactical KPIs and a set of services. These services are 
collected in the toolbox. A short cyclic consultation monitors the extent to which the tactical 
KPls are achieved with the services. If needed, adjustments can be made in the toolbox. 

An overview of the different KPI types, including examples, is shown in the next table. 


Table 2. KPI framework 


KPI type Strategic KPI Tactical KPI Operational KPI 


Example Less pollution in the Avoid traffic on link X Number of rerouted 
region users on link X 





Task 2: Monitor and adjust 

Based on data from the Assessor (from the Waterfall reports), the Strategy Table examines 
whether the strategic KPIs are being achieved, or whether adjustments are needed. If 
adjustments are needed, this is further shaped by the Network Manager. This creates a 
feedback loop - based on data from the Assessor - between the Strategy Table and Network 
Manager. 


The Strategy Table also monitors whether the predefined win-win-win is met. If needed, 
adjustments can be discussed at the Strategy Table. 


An overview of the new four intermediary roles is shown in the next table. 
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Table 3. Intermediary overview 


Tasks and 
responsibilities 


Merge and 
complete data 
Define view of 
current and 
predicted traffic 
state 


Public and 
private data 
providers 
Network 
Manager 


Relationships 


Conditions 


Reliability view 
Willingness of 
parties to share 
data 


Find and define 
common goals 
and KPIs 

Make 
adjustments 


Participants are 
road authorities 
and automotive 
industry/service 
providers 
Assessor 


Dialogue 
Possibilities 
to measure 
performance 


Develop toolbox 
(services) 
Optimise 
algorithms 
Automatic 
activating service 
requests 


Both automotive 
industry/service 
providers and 
TMCs 

Network Monitor 
and Strategy 
Table 


Quality and 
explainability 
service requests 
Willingness of 
parties to follow 
up on service 
requests 


Monitor, assess 
and feedback of 
performance 
Determine 
added value of 
cooperation (per 
role/partner) 


Both automotive 
industry/service 
providers and 
TMCs 

Strategy Table 


Independency 
and auditable 
Trust between 
parties 


Dependencies Little or none; Quite a lot within | Guided by Little or none; 
support role the region Strategy Table neutral role 
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2.3 A common digital language for exchanging TM information 


Background and approach 





Within the SOCRATES? project, a conceptual architecture for the exchange of traffic 
management data between the participating partners was established under the working 
title TMex. 


The overarching goal was to harmonise data exchange by establishing common data 
description mechanisms and interfaces for all partners to use. The harmonised data exchange 
was applied across the SOCRATES?” pilot sites, and is also envisioned for a future Europe-wide 
roll-out of similar deployments of interactive traffic management. 


During the project runtime, a harmonised data exchange was approached via a conceptual 
phase, looking at partner requirements and pilot site specifics. Based on those, a technical 
development was initiated of concrete data formats. 


A major focus point of this activity was the interaction between traffic centres and service 
providers, called the TMex interface. 


The figure below shows the overall architecture, with the TMex interface positioning in 

the context of SOCRATES”? pilot sites. On the left, the TMCs are shown. Traditionally, 

they provide their data streams in a wide variety of protocols from the domain of road 
authorities (e.g. DATEX II, IWERA4 and RSMP). On the right, the service providers are shown. 
Usually, they deal with data formats that are rather industry-based (e.g., TPEG). The TMex 
interface concept connects the two to define a common way of exchanging data that is 
based on existing formats as much as possible. In the SOCRATES2.0 deployments, such 
connections may be supported by one or many intermediary roles, as introduced in Section 
2.2. Here, TMex is also applied for any data exchange mechanism between TMCs, service 
providers and the intermediaries. 
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TMex’ scope in SOCRATES?° 


TMex interface 


Traffic Management 
Centers SOCRATES?” Service Providers 
intermediary 


SOCRATES?” 
intermediary 





FAST SAFE GREEN SOCRATES2° 


Figure 8. TMex scope in Socrates”? 


The data exchanged in this context relates to sharing information and requesting services. 
The requesting services is route-related data that simultaneously supports optimal individual 
routes and serves the collective KPIs in terms of flow, environment, etc. The sharing 
information supports a common operational picture so all stakeholders can observe the 
traffic situation and take measures to optimise the situation. 


An important baseline for the data format harmonisation was found in DATEX Il, a 
well-established electronic language used in Europe for the exchange of traffic information 
and traffic data. 


First, we took a number of data models from DATEX Il for requesting services and sharing 
information and further enhanced and expanded them to meet the SOCRATES20 use case 
requirements. After that, we ‘cut out’ the relevant data elements and compiled a lean 
profile without any unused data elements. 


Based on close interaction between the SOCRATES? deployment partners and DATEX II 
experts, a DATEX Il-based messaging concept was developed for the specific use cases and 
pilot sites. This resulted in updated DATEX II profile specifications for the three following 
topics: 


e TMPlan for smart routing and avoidance 
e Regulated zones for environmental zones 
e Roadworks 





€ De Vries, Bard, 2021. Why DATEX Il is a strategic choice, Presentation at: 6th DATEX Il Forum, November 2020, https://datex2.eu/ 
sites/default/files/2020-12/2020.11.25%20UF%20Webinar%20-%20D2%20as%20a%20strategic%20choice.pdf 
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The DATEX Il-related elaborations, and experiences with them during the pilot deployments, 
could also be of relevance to actors outside the project. In particular the profile specifications 
could be reused and further enhanced in follow-up activities. The next section further details 
these profile specifications. The section after that summarises pilot-site-based experiences 
and recommended follow-up actions. 


Further functional details on the usage of the profile specifications are presented in the 
pilot site reports’. 


Harmonised DATEX II profiles 





DATEX II profile: Traffic Management Plan for network optimisation 
This profile aims to communicate service requests (avoid/reroute) between the Network 
Manager and service providers in the SOCRATES?! Optimising Network Traffic Flow and 
Smart Destination use cases. 


Corresponding message elements include a location reference to effected links and 
alternative routes, the reason for the service request and the start-time and expected end- 
time. In the other direction, service request responses are communicated, containing accept 
or decline information. 


This profile development is based on a combination of: 


e TMPlan extension of the DATEX Il group 
e The strategic routes profile from the German MDM extension 
e OpenLR additions from DATEX II 3.0 


The result of this elaboration is provided online, allowing for it to be used outside 
SOCRATES? It includes a schema file (XSD), example files (XML), a model file (EAP) and 
some accompanying textual guidance: 


https://www.datex2.eu/implementations/extension_directory/extentions-smart-routing- 
and-avoidance 








DATEX II profile: Environmental Zones 

This profile was newly developed within the SOCRATES? project. It serves to communicate 
the location and characteristics of environmental zones, allowing drivers to react before 
they enter an environmental zone. 


The profile is considered a major achievement. It addresses the current digitalisation 
needs to efficiently deploy local access regulations, and assists with environmental zone 
regulations currently being imposed in many cities across Europe. 





7 See reports “The SOCRATES?” pilot in city of Amsterdam”, “The SOCRATES”! pilot in city of Copenhagen”, “The SOCRATES”? pilot 
in city of Munich”, “The SOCRATES?” pilot in city of Antwerp” 
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The Environmental Zone profile development is based on a combination of other profiles 
for the domains of traffic regulations and the UVARbox project (see Section 5.6). 

The result of this elaboration is provided online, allowing for it to be used outside 
SOCRATES?*. It includes a schema file (XSD), example files (XML), a model file (EAP) and 
some accompanying textual guidance: 


https://www.datex2.eu/implementations/extension_directory/socrates-20-regulated- 
access-zone-publications 








DATEX II profile: Road Works 
This profile aims to communicate planned and actual roadworks from a road authority to 
an intermediary in the Road Works use cases. 


The main goal of building this DATEX Il profile was to allow the intermediary to harmonise 
the data feeds from various (Dutch, German and Flemish) road authorities. All data feed 
from the partners was aligned with a harmonised, agreed-upon dataset. Information was 
added if one of the partner's data feed had specific useful information. 


Within the Road Works use case, a number of information objects were defined that had 
to be included in data communication with the stakeholders of the use case. The fields 
included the following: 


e probability of occurrences 
e probability rate 
e number of occurrences 


In order to make this work, the Road Works container, as defined within DATEX II, had to 
be extended. A practical approach was foreseen within the project, in which the existing 
DATEX Il object would be extended with the above fields (inserting). This method work 
sufficiently when the roadworks event was already available in the DATEX Il feed from 
the road authority. If the roadworks event was new (not yet known to the road authority), 
a new event needed to be inserted. A smaller or more compact container is suggested 
for this purpose, as service providers are unable to provide all the same fields that are 
available within a DATEX Il message. 


Within SOCRATES2%, a conceptual data model was developed for the proposed Road Works 


container, however no final DATEXII profile was defined. This work will be concluded in a 
future elaboration by the European DATEX Il working group. 


Pilot-site experiences and outlook 





Interviews with SOCRATES2.0 deployment partners provided insight into the viability 
and efficiency of the elaborated DATEX II profiles. The partners spoke about whether 
the profiles sufficiently met the need of the pilot site and use case, and whether they 
encountered any problems when using them. 
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Altogether, the DATEX Il-based messaging concept in the SOCRATES?” pilot environments has 
proven itself. There were clear benefits to using a harmonised data format for the interactive 
traffic management concept. Most importantly it improved the efficiency and allowed 
transferability between the individual deployments and communication partners involved. 


The choice of DATEX II, a well-established European approach, is considered beneficial and 
proved to be a good baseline for a uniform approach, with promising perspectives in terms 
of interoperability and sustainability. 


We also identified a certain level of flexibility in how messages are composed within 
DATEX II. Sometimes, messages could be formatted in different ways to achieve the same 
goal. This meant that when drafting a message, both the sender and recipient had to be 
consulted. Since the DATEX II messages are not entirely self-explanatory, we recommend 
they be accompanied by an explanation to avoid misinterpretation. 


Furthermore, some open issues were identified regarding the efficiency of DATEX Il-based 
communication. A crucial point regarding service request messages is the ability of service 
providers to incorporate the alternative route from such a message in their navigation 
algorithms. Another crucial point relates to road works information, which originates from 
varying data sources. Data harmonisation of such information depends on uniform source 
data formats, which so far has revealed many inconsistencies. So further harmonisation 
and usage guidance would be beneficial here. 


These outstanding issues are further discussed in the Follow-Up Plan in Section 5.2 


2.4 Communication to road users via information and navigation services 





One of the innovations in SOCRATES? is the involvement of state-of-the-art road user 
services, such as information and navigation services embedded in smart phone apps or 
as connectivity features of OEMs. According to the cooperation framework (see Section 
2.2), service providers play a crucial role in the SOCRATES?” architectures by, among others, 
distributing service requests coming from TMCs to individual service users. 


The reason to engage service providers in our concept corresponds to one of the overall 
project's goals: to advance with traditional traffic management schemes. Considering 

the increasing penetration of private-party services, the increasing connectivity of road 
users and cars via cellular networks, and the increasing complexity of traffic management 
concepts, we feel that traditional channels, such as traffic radio and VMS, are not sufficient 
anymore, and need to be complemented by new channels provided by service providers. 
This increases the outreach and efficiency of public-body traffic management schemes, 
but also improves the service quality of private services. With the road users experiencing 
more qualitative services, we again address the win-win-win of SOCRATES?°. 
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In any of the SOCRATES?” pilot deployments, private-party information and navigation 
services were an integral part to showcase the new opportunities arising from this concept. 
Inthis context, some existing services were upgraded with new features, or new services 
were installed. 


Next, we want to highlight some of the innovations developed by the service providers 
participating in SOCRATES?°, indicating how these innovations look like in practice and how 
they can contribute to the interactive traffic management concept. 

Furthermore, we discuss how service providers see their role in interactive traffic 


management deployments, and what the future directions might look like. 


Innovative service solutions in SOCRATES?” deployments 





The following example shows how existing end-user services were upgraded to allow 
innovative traffic management schemes, as part of the SOCRATES?! deployments. 

In the Antwerp Smart Tunnel service? we deployed a proactive routing of travelers over 
two alternative tunnels crossing the Scheldt river. To do so, the following functionalities 
were implemented: a reroute advice, based on the current network state, and an awarding 
mechanism, via a tunnel toll reduction. 


These functionalities were implemented within the Flitsmeister navigation app by 
Be-Mobile and the BMW in-car app, see the next figures. 
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Figure 10. BMW Smart Tunnel Drive Service 





8 See report “The SOCRATES?” pilot in city of Antwerp” 
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Both services inform about the applicability of an alternative route, depending on the 
traffic state and expected travel times. They further instruct the driver on how to use the 
toll reduction via a voucher, to be shown at the tunnel entrance. Whereas the first feature 
is well-known from conventional routing apps, the toll reduction is a best example of how 
additional features with a traffic management focus can be seamlessly integrated in such 
apps. Here, a well-elaborated interaction between the service's engines, the driver and the 
tunnel operators (who check the vouchers) was established. 


lt is evident that a such use case is barely feasible with conventional channels (e.g. via 
VMS). Also, an approach without integration (e.g. with a separate app for the voucher) 
would likely not be very convenient for the driver. 


In the next example, we showcase how parking guidance is embedded for drivers who 
are on the way to a bigger venue (stadium, arena, etc.). In this case, the benefit is not only 
for the TMC, by proactive management of incoming traffic, but also for service providers, 
as their navigation services are expanded for the ‘last mile’ (i.e. for the path to the final 
parking destination). Such a last-mile service is rarely implemented in today’s navigation 
apps, at least not for big-venue locations with multiple and dynamically-filling parking lots. 


The BrandMkRS Smart Destination service in Munich? aims to provide routing advice to 
event visitors. This is realised by targeting and approaching users on social media (via 
Facebook, WhatsApp, Google Maps, and text messages). Users can register and, in return, 
are provided with relevant information (see the next figure). On the day of the event, the 
user receives a route with the best access and parking destinations. This information is 
aligned with the user's original route, and the current traffic and parking situation. 


Here, we trialled social media as an emerging communication channel, so far rarely exploited 
by traffic managers. A similar parking information service was delivered by BMW, again via an 
in-car app. 
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Figure 11. BrandMKRS Smart Destination service 





9 See report “The SOCRATES?” pilot in city of Munich” 
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Another expansion to existing navigation services was showcased in the Speed and Lane 
Information use case in Antwerp. Here, the Flitsmeister navigation app by Be-Mobile was 
upgraded to mirror lane-control information (i.e. lanes open or closed, speed limits) from 
the lane-control system of the TMC (see the next figure). 


Here, we complemented the strategic traffic management (route advice with voluntary 
compliance) with tactical traffic regulations (lane control with obligatory compliance) within 
one end-user service. The expectation is to increase the awareness and acceptance of such 
traffic regulations. As a side note, this raises the (long-term) guestion whether conventional 
lane-control systems, which operate via expensive VMS, could be replaced at some point. 


| = Malden Melden 


i 


—— 


(20) 


119 





Figure 12. Speed and Lane Information by Be-Mobile 


Lastly, we look at how access regulations, as an emerging traffic management scheme 
in many European cities, can be embedded in conventional navigation services. Here 
we deployed information about static and (partially) dynamic environmental zones in 
Amsterdam and Copenhagen”. 


Be-Mobile and TomTom demonstrated corresponding functionalities in the TruckMeister 
app and the AmiGo app (see the next figures). It seems evident to use navigation apps 

to disseminate such information, as such information is otherwise hard to communicate to 
drivers, especially for foreign visitors who are not familiar with local rules. 





10 See the reports “The SOCRATES?" pilot in city of Amsterdam”, “The SOCRATES?” pilot in city of Copenhagen” 
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Figure 13. Environmental zones service by Be-Mobile 
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Figure 14, Environmental zones service by Be-Mobile by TomTom 
Based on these examples, we learned the following: 


e From an end-user perspective, the services are focused on clear and direct information 
about the traffic situation and travel options. There are no hints about the underlying, 
sometimes complex processes of communication and negotiations between service 
providers, TMCs and intermediaries. This simplifies the user interaction, and works 
towards understandability and acceptance of the traffic management advice. 
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e (In most end-user services, there is a freedom to follow and comply with a traffic 
management scheme. This is done by, e.g. actively accepting or denying a reroute 
advice. Further, some services offer a feedback function, verifying the acceptance 
and behaviour of a user. With the user being in full charge of his or her decisions, and 
allowing communication back to the service provider, this corresponds to our vision of 
the ‘customer as the CEO of the journey (see Section 2.1). 

e Multiple service providers can operate in parallel in the same use case, even with 
different communication channels (smart phone app, in-car app, social media). This is 
important as we expect that there is no one-size-fits-all end-user solution, but that we 
need to utilise all existing and upcoming channels and technologies. As service providers 
are usually at the forefront of such advances, this is a clear argument to have (multiple) 
service providers as integral parts of use cases. 


Service provider's role in interactive traffic management 





The service providers who participated in SOCRATES? reflected on their contributions to 
the project as well to the entire concept, and laid down their understanding of their role in 
future deployments. 


One of the main arguments for their involvement is that service providers know well how 
to communicate with their customers via their channels, as this is part of their business 
model. Thus, reliability and benefits to users are one of their main strengths. Further, 
service providers feel that their individual and direct services can enable individualised 
traffic management (which has been more collective so far) and increase credibility when 
transmitting traffic management information. 


This means they can individually address road user characteristics and demands. This 

was evident in the Smart Destination use case, where selected parking destinations were 
displayed depending on the user's route, or the Optimising Network Traffic Flow use cases, 
where a reason was communicated why a specified route should be avoided. Clearly, 

such features are impossible through the conventional communication channels of road 
authorities. 


However, service providers also stated that they rely on the competence and knowledge 
of road authorities or TMCs, as they know more about things like the overall current and 
predicted traffic state. In conclusion, the combined strengths of services providers and 
TMCs provide the best benefit for the road user. 


One interesting discussion item was on the final implementation of traffic management 
measures, as defined by the TMCs, within the private-party services. It is considered 
problematic if TMC-based information directs user behaviour too explicitly (e.g. ‘follow 
route A’). Such a request cannot be integrated in the existing concerted systems of the 
service providers, especially not in their routing machines. Service providers need to 
interpret such requests to address the right target groups in the right local context. 
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Instead, an SR should be composed as an indication of areas to avoid, with a detailed 
description of the underlying cause, the intended impact and the following traffic 
management operations. This information could be processed more expediently from the 
service provider's systems, resulting in a user-beneficial service. Altogether, TMC-based SRs 
should address the problem and the cause very specifically, but not the solution itself. 

This problem orientation instead of solution orientation when communicating between 
TMCs and service providers is an important aspect. It counteracts the statements of some 
ITS stakeholders that navigation apps should purely be used a ‘fulfilment assistant’ for 
TMCs. In the perspective of service providers, they still prefer to independently design and 
control their own technical assets (i.e. their systems), algorithms and user interfaces. 


However, mutual benefits for both TMCs and service providers arise when TMC-based 
information is formatted in a way that can be easily integrated into service provider's 
systems. A positive example is the avoid route mechanism within the SRs, as demonstrated 
in SOCRATES2°, which can be much better reused by the service providers than the similar 
reroute mechanism. 


There seem to be even more promising perspectives for mutual benefits when deploying 
impact-driven and rewarding approaches, such as pioneered in the SOCRATES? Antwerp 
tunnel use case. In a context like this, service providers can be put in the middle of 

the value chain of traffic management, possibly with new (monetary) value creation 
opportunities. 


Altogether, service providers are ready to engage in future deployments of interactive 


traffic management by contributing their strengths and assets and cooperating at eye level 
with other partners of the concept. 
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3. INITIATING SOLUTIONS 
OF INTERACTIVE TRAFFIC 
MANAGEMENT 
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This chapter is all about recommendations and lessons learned within SOCRATES2° when 
preparing interactive traffic management solutions. We elaborate on the governance 
before detailing the solution to be implemented. We also provide insights into the design 
phase by presenting the structured approach. We guide the reader through the process 
based on the work executed in the SOCRATES? design activity and examples from the pilot 
site activities. 


The following figure defines the stepwise approach elaborated, which can be interpreted as 
a roadmap for the deployment of interactive traffic management solutions. This approach 
builds on a roadmap already initiated in SOCRATES?” Activity 3" (see the figure below), but 
adds experiences gained during the deployments, especially business perspectives of such 
deployments. 


Initiating solutions of ‘interactive traffic management’ 
A STEPWISE APPROACH 


INITIATION PHASE 


Shared Common Solution Cooperation 
Vision Mission area model 


ORGANISATION PHASE 


Collaborative 
business 
approach 


Use case Required 
selection roles 


Legal 


Governance 
framework 


DESIGN PHASE 


Legacy KPI Role Use case 
systems Definitions assignment elaboration 
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Figure 15. Roadmap for deployment of interactive traffic management 


In a nutshell 
e It starts with an initiation phase with the following iterative steps: 


Co-creation of a shared vision 

Identification of the common mission 

Investigation of the solution area and a high-level description of the improvement 
Pre-selection of a cooperation model 





PWN Ss 








11 See the report “Setting the stage for the deployment of interactive traffic management” 
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e It continues with what we call the organisation phase; this phase consists of iterative 
steps: 


1. Setup of an appropriate governance 

2. Selection of use cases considering local context and providing a detailed 
description of the use case mission 

3. Identification and selection of required roles and capabilities of (potential) partners 
Elaboration on the win-win-win and collaborative business approach 

5. Legal framework for cooperation 








e Inthe design phase, the use case is further elaborated in iterative steps: 


1. Identification of existing legacy systems, services, data sources, interfaces, 
appropriate standards, and an inventory of required and available expertise 

2. Definition and agreement on KPls 

Final assignment of the required roles, tasks and responsibilities 

Elaboration of the use case and system architecture (e.g. functional information 

flow diagram, sequence diagrams, high-level technical architecture and data 

exchange formats) 
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The next phases are at the operational level: development, testing, implementation and 
evaluation’. In this chapter we do not elaborate on those. We elaborate on the first three 
phases using the example of the Optimising Network Traffic Flow (ONTF) use case. 


3.1 Initiation phase 


The initiation phase is the starting point for organising the public-private cooperation to 
initiate interactive traffic management. This Chapter 3 primary covers the Coordinated 
Approach model (see Section 2.2). This model is based on our SOCRATES?° experiences 
from real-life tested use cases at four pilot sites. The first phase enables cooperation 
between partners who are not yet familiar with each other. It is advisable that one party, 
often the public road authority, formally initiates the cooperation and provides some form 
of steering. However, any of the partners can take the initiative and propose a cooperation. 


This phase may need several iterations to reflect new insights and allow new stakeholders 
to get on board. As this phase lays the cornerstone for all following activities, a thorough 
elaboration is recommended. Changes can still be applied in later stages, but will require 
more efforts. 





12 See the SOCRATES?! Final Evaluation report and the reports “The SOCRATES?” pilot in city of Amsterdam”, “The SOCRATES?® 
pilot in city of Copenhagen”, “The SOCRATES?” pilot in city of Munich”, “The SOCRATES?” pilot in city of Antwerp” 
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Step 1: Co-creating a shared vision 

The shared vision builds on the principle of creating benefits and value for all stakeholders 
in traffic management road users, public authorities and service providers. This is the win- 
win-win in our concept. Based on the established individual and common goals addressing 
the problem and needs, a set of high-level benefits is identified for each partner. The 
quantification and valuation of these benefits are the elements that define the ‘win’ for 
each of the stakeholders. 


The sessions that facilitate this initiation phase not only provide a good use case, 
knowledge exchange and relationship building between the public and private parties, 
but also contribute widely to developing the necessary understanding of each other's 
cooperation needs, constraints and opportunities. All these aspects contribute to the 
development of a shared vision for cooperation between all the partners. Ultimately also 
a solid level of trust is established between all parties, supporting the right setting for 
aligning individual goals and services into common goals. 


Shared benefits 


ROAD USERS ROAD AUTHORITIES/ SERVICE PROVIDERS/ 
TRAFFIC CENTRES AUTOMOTIVE INDUSTRY 
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Figure 16. Shared benefits 


Step 2: Identify the common business mission 

At the start of a new cooperation the public and private organisations involved share their 
initial insights and knowledge of the initiated mission (e.g. congestion or accessibility within 
a specific area, region or country). They also briefly introduce their proposals and available 
assets and resources that can contribute to the mission. Public partners describe current 
and future challenges and define the agreed goals and strategy. That also includes the 
available traffic management systems and services used to tackle the problems. Private 
partners present their expectations, goals, solutions and opportunities (roadmaps) for 
their current and planned services. These include both data and end-user services for 
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information and navigation. The decision to proceed with a cooperation should be based 
on a positive joint assessment that the sum (or combination) of the presented proposals, 
assets and resources is valuable and contributes to the mission and general solution. 


Step 3: Investigate the solution area and scope 

Potential partners operate on different geographical levels (regional, national, European 
and worldwide) and must determine the outer boundaries of the intended solution. So the 
questions include: What road types and road users are considered? Is public transport and 
P+R included? 


Also, more detailed information on the solution area can be provided such as the provision 
of route recommendations using roadside infrastructure and navigation services. Based 
on the information from the solution area, the required capabilities can be derived. In 

this case, that involves displaying advice via roadside infrastructure or routing advice via 
connected (navigation) services. When pre-selecting suitable cooperation models, the 
information gathered for solution area plays an important role as it already identifies 
potential stakeholders. The type of stakeholders identified influences the selection of 
suitable cooperation models, as the preferred cooperation model will influence the 
selection of required stakeholders 


Main problem: Sub-optimal distribution of traffic over 2 river crossings (caused by tolling costs). 
[Users/services do not (sufficiently) follow advice from RA; routing services do not consider dynamic tolling costs] 
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— What should it look like after implementation? — Better distribution of traffic over 2 river crossings. 

— How to evaluate successful implementation? — Measure traffic intensities before and after implemen- 
E tations. 


ait 8 ane 
— What measures will improve the situation? — Advise travellers to switch routes, … 





FAST SAFE GREEN SOCRATES2° 


Figure 17. Pilot site Antwerp, use case ONTF - business problem and solution area. 


The use case description finally outlines the agreed solution area from the user perspective 
and is related to the common problem that the cooperation aims to solve. At the start of 
the new cooperation, multiple high-level use cases for the problem can be created and 
evaluated in terms of viability, usefulness, feasibility and scalability. Gradually working 

on the use cases is the core for progress in terms of design, organisation, development, 


43 


operations and improvement. The complexity of the use case depends on the ambitions 
and resources the partners bring together. In the next phase (3.2 organisation phase) 
partners dive into the details of the selected use case(s). 


Step 4: Pre-selection of cooperation model 

The cooperation model details are selected based on the initial shared vision (step 1), a 
first glance at the common business mission (step 2) and possible solutions (step 3). The 
SOCRATES22 cooperation framework provides the tools for this. Partners show and explain 
their interest in taking up one or more roles. Missing stakeholders (e.g. adjacent road 
authorities who may have an interest) are identified and invited to join the cooperation. 

In this phase the cooperation is still volatile, since the participating partners are not yet 
definite and the roles not yet assigned. Potential conflict of interests can rise to the surface 
but do not need to be solved in this phase. They could however lead to partners leaving the 
cooperation, or prevent trust building. 


3.2 Organisation phase 
In the organisation phase we look at the following iterative steps: 


1. Setup of an appropriate governance. 

2. Further elaboration of the use case(s) to solve the collective problem, considering 
local context and providing a detailed description including use case goals, boundary 
conditions and main stakeholders. 

3. Identification and selection of required roles and capabilities of (potential) partners. 
Elaboration of the win-win-win and collaborative business approach. 

5. Legal framework for cooperation. 





Step 1: Governance 

The selection of the cooperation model has an impact on the governance, which needs 

to be set up to build the organisation structure of the cooperation. Interactive traffic 
management for simple solutions (e.g. data exchange) require a pragmatic governance. For 
the more complex use cases (e.g. coordinated actions), a more elaborated governance is 
needed. Aspects that the governance should address are: 


e Progress on collective results 

e Maintaining a trusted environment 
e Representation of partners 

e External stakeholder management 
e Management of the cooperation 


In cooperation there should always be a healthy balance between individual partners and 
collective interests. With collective interest, we mean the expected results of all partners 
combined. The management of the cooperation should first focus on the collective results 
without jeopardising the individual interests. In order to build and maintain the trusted 
environment of the cooperation, parties should agree on a set of principles and rules of 
engagement: the choice and nomination of each party's representatives, the chair and 
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support of the cooperation, the communication and meetings, and the do's and don'ts to 
build and maintain trust. These principles and rules are important not only for the initial 
or current partners but also for the introduction of new partners and the departure of 
partners occur. 


Step 2: Use case selection 

In step 2, a working group is established to elaborate on the high-level description of a 
specific challenge in a use case. The following format can be used, containing a summary, 
background, objective, expected benefits and variations. 


Then a decision is made on which use case variant is preferred. Aspects to consider here 
include the following: 


Match with the shared vision. 

Relevance for end users. 

Added value for collective mission and problem. 
Most appealing for each partner. 


PUNS 


As an example, in SOCRATES?° we started with 20 use case variations, then brought that 
back to 14 and finally we choose the top 5 for deployment. 


Popularity contest - Top 5 
0 1 2 2 4 
UC_SR_01: Optimizing network traffic flow 
UC_SR_02: Individual routing towards public event locations 
UC SLA 01: Maximum allowed speed 
UC SLA 02: Speed advice “Congestion ahead” 
UC SLA 03: Speed advice “Head of Congestion” 
UC SLA 04: Speed advice at Traffic Lights 
UC SLA 05: Speed advice at schockwaves 
UC SLA 06: Lane information 
UC SLA 07: Lane advice at short on- and off-ramps 


UC SLA 08: Lane advice atr Traffic Lights 


UC LIHW. 01: Road Works Warning 


UC LIHW. 02: Road condition warning 
UC LIHW. 03: Emergency Service protection 


UC LIHW 04: Enviromental/Areal information and constraints 





Figure 18. example of use case selection 


A mission was Stated for each intended use case deployment. A use case mission is a 
general statement of how you aim to achieve the vision. In this phase, multiple variations 
of the use case are possible. However, the use case mission remains the same and should 
provide guidance for the underlying details. 
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MISSION: 


— Optimise network traffic flow. 
— Improve distribution of traffic over 2 river crossings 
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In such a manner 
that we obtain a: 


— WIN for RA 
— WIN for SP 
— WIN for User 
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Figure 19. example of solution mission 


Step 3: Identification of required roles 

This step is about building the cooperation in terms of roles following the SOCRATES?° 
cooperation framework. In this phase partners are not yet assigned roles. The focus here is 
to detail the required roles and attached tasks to those roles. 


Table 4. Example of role/task detailing 


Provide required data to Network Monitor / clarify quality 
Strategy Table Create win-win-win / align public and private goals / define KPIs / set 
up toolbox / monitor (& redefine) strategic goals and KPIs 


Network Monitor Collect aggregated data from public and private data providers / fuse 
data / predict state of the network / assess data quality / respect 
data agreements 


Network Manager Configure KPIs / create problem state / identify an effective scenario 
to solve the problem / send service requests / evaluate and improve 
scenario 


Assessor Validate partner impact / report on impact and KPIs / virtual 
rewarding / data archiving 


Service provider Receive and assess service requests / activate routes / measure own 
impact and inform Assessor 


Traffic management Receive and assess service requests / activate routes / measure own 
centre impact and inform Assessor 
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Step 4: Aligning and elaborating the business approach 
Based on lessons learned and experiences from four pilot sites, multiple business ideas 
emerged for the different SOCRATES?! cooperation models (see Section 2.2). 


We structured the business growth process along the following three stages of maturity: 


e Piloting stage (e.g. what we did in the SOCRATES?! project) 
e Effort-driven business model stage 
e Impact-driven business model stage 


In the first piloting stage, trust needs to be built between partners before cooperation can be 
effective. Learning and building trust for a sustainable cooperation are the main objectives 
in this stage. No immediate impact on public and private long-term goals can be expected. 
Short-term goals for this stage are building a common understanding on required content, 
suitable cooperation model(s), experience and assets each party can bring to the table. The 
first iteration of this stage can be challenging and time consuming. But after establishing a 
first concept of the technical chain, later improvements or iterations go faster. 


The intended procedure is to start with the piloting stage, then move to the effort-driven 
business model, and after that the impact-driven business model. Stages can be skipped 
depending on the complexity of the use case and number of partners. Note that the 
impact-driven business model is only viable for the Coordinated Approach, where a change 
in end-user behaviour is needed to create impact. When partners do not have a mutual 
gain for sharing data/information with the end users, an effort-driven business model can 
be considered. 


Pilotsite Business Models SOCRATES2° Business Models 


Impact driven stage 


KF : Effort driven stage 


Piloting stage 
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Figure 20. Stages for creating business models 
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Depending on the stage of maturity, the details on the collective business model are 
worked out by the partners. See chapters 4.4 and 5.3 for more details regarding business 
models. 


Step 5: Legal framework for cooperation 

Working together at a piloting stage is a financial challenge and risk for most partners. 
There is no clear business model or guarantee that individual goals will be met. So to cover 
the initiation costs, a governmental subsidy or compensation is advised. The distribution of 
the subsidy should be related to the resource contributions of partners. 


In relation to the cooperation framework, a legal and financial framework is needed to 
progress on the collective business development. Legal-financial aspects that need to be 
explored are the following: 


e Procurement of services and paying for delivered impact 

e Flexible procurement due to the pace and changes of new technology 
e Dealing with how to reward road users in relation with the tax system 
e Management of intellectual property rights 

e Agreement on data ownership 

e Considering GDPR requirements 


A more detailed outline of this step still needs to be discovered and experienced in future 
research and deployment projects. In SOCRATES2®, only first experiences in real-life 
environments were captured, discussed and reflected on in Section 4.1. We determine 
that current legal and financial frameworks still provide several constraints that need to be 
solved first to create an equal public-private cooperation. 


3.3 Design phase 


In the design phase, the use case is further elaborated in iterative steps: 

1. Identification of available legacy systems, services, data sources, interfaces, appropriate 
standards and an inventory of required and available expertise. 

2. Definition and agreement on KPls.. 

Final assignment of the required roles, tasks and responsibilities. 

Elaboration of the use case and system architecture (e.g. functional information flow 

diagram, sequence diagrams, high-level technical architecture and data exchange 

formats). 








Rw 
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Step 1: Identify legacy systems 

Interactive traffic management is rarely built from scratch. In most cases, local, regional 
and national traffic information systems, procedures and standards already exist to a 
certain extent. There are multiple aspects to consider here: 

e TMC central systems (e.g. decision support) 

e Roadside equipment (e.g. actuators) 

e Private end-user services 

e Existing user base 

e Data types, data collection and data coverage and quality (sensors) 

e Exchange formats and standards 

e Specific expertise 


An elaborate investigation should be conducted of existing systems, services and 
procedures (e.g. on decision support) in TMCs and on the roadside (e.g. VMS, ramp 
metering, traffic controllers). Also, service providers need to clarify what services (e.g. 
in-car, navigation apps, social media) can be made available and how this can be done. 

It is also important to know how many active users can be reached or recruited for new 
services. What data sources, sensors and monitor systems are in place and whether that 
data is suitable and available for the intended use case. Identify existing interfaces and 
standards for data exchange. Create an overview, detail pros and cons, and decide for each 
interface which standard data exchange profile is most appropriate. Note that multiple 
standards may be available for each interface, but avoid developing new ones. Last but 

not least check the required and available technical standardisation expertise; DATEX II in 
particular. The main role for DATEX Il experts is to guide partners to existing formats and to 
support the usage of those formats, not to create new variants. 


Existing services 


Services provided by RA: 


* Route recommendations on VMS 
¢ Travel recommendations on VMS 


Measures provided by RA: 
* Rerouting in case of accidents 


¢ Temporary suspension TOLL LFK-tunnel in 
case of accidents 


Services provided by SP's: 


* Private navigation services 
(TomTom, Flitsmeister, Waze, HERE, BMW) 
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Figure 21. Identified existing services 
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Step 2: Definition of KPIs 

Translate the identified and agreed common goals into an initial set of KPIs to measure the 
impact and functioning of the jointly developed service(s) at a strategic level. This is done to 
manage and monitor the performance and success of the cooperation. 


These strategic goals then need to be translated into operational KPls and are used to 
determine the network problem state. The definition of suitable KPls is also crucial for 
identifying relevant data for evaluating the impact of services that will be needed for 
impact-driven business models. 


Step 3: Assignment of roles and tasks 

Part of the use case progress is the distribution of roles among partners. Some intermediary 
roles can be integrated and/or conducted by the same partner. This involves considering who 
can perform the needed role best. This also depends on legacy, ambition and the position of 
different partners. A basic structure of roles and responsibilities is designed for the specific 
goals of the use case. The roles are: intermediaries, data providers and service providers and 
the TMCs. More or fewer functions (or tasks) can be added to each role to develop a tailored 
cooperation framework. The added value of each role should be made measurable. 


Table 5. Example of public-private role distribution 


Network Monitor 


ENE GENE 


ENG: MENEER FEE 
Service provider BMW, Be-Mobile TomTom, 
BrandMKRS 
Data provider HERE, BMW, Be-Mobile, NDW, 
TomTom 
Traffic management centre RWS AMS PNH N 


Step 4: Detailing the use case 
Looking at the example of the ONTF use case in Antwerp, we will elaborate on detailing the 
use case. 





This use case aims for a better distribution of traffic on the ring road around the city, 
especially when the southern part of the Kennedytunnel (B) becomes congested and there is 
still capacity on the northern part passing the Liefkenshoektunnel (A), which is a toll tunnel. 
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Figure 22. Antwerp ONTF Scenario 


When detailing the use case, we recommend starting with a detailed look at the different 
levels: 


e Strategic level - describing the policy goals e.g. (1%) increasing network efficiency; (2"°) 
reducing emissions and improving traffic safety. 

e Tactical level - describing the target level, e.g. Distribution of traffic flows over the two 
river crossings > optimal distribution. 

e Operational level - detailing on the actual measures to be taken e.g. RA: Impose 
(dynamic) toll, and SP: Advise users to take certain routes, ... 

e Situational level - elaborating on the status or situational picture e.g. Actual traffic 
conditions, actual distribution of traffic flows, origin-destination patterns. 


It is also helpful to use an appropriate template to describe the use case(s). 


51 


SOCRATES?2° 


<<function>> <<part of role>> MAL ee CREED 
<<responsible partner>> <<supporting partner(s)>> 


<<description of function>> 


<<description of interfaces and output/input>> 





Figure 23. Use case function template 


In asecond step, a system overview can be sketched including the levels mentioned above, 
naming the contributing parties, adding existing and required new roles and services and 
the relationship between them. 


System Overview - Socrates service CM4 








sa LA OR Oe 


SITUATIONAL 





Figure 24. System overview Antwerp ONTF 


In a third step, it is advisable to accurately record and agree on: 
pre-conditions - activities that must take place or conditions that must be true before the 


52 


use case can be started. 


e post-conditions - state of the system when concluding the use case. 


Pre-conditions - CM4 


Pre conditions: activities that must take place or conditions that must be true before the use case can be 
started: 


* Tasks, roles, responsibilities need to be elaborated, identified & agreed. 
* Sufficient amount of test users available. 

+ Agreed toll- and rewarding system (also external stakeholders). 

+ Agreed monitoring system. 


* Definition of location and trigger condition that activates the measure (detour recommendation for travellers passing Kennedy 
Tunnel plus toll reduction) > e.g. splitting percentage in use of Kennedytunnel vs Liefkenshoektunnel is expected to reach a 
certain threshold level epee A 


* Definition of protocol to be used and minimum profile requirements to be met for detour recommendation and toll reduction 
message. 


* Definition of location and trigger condition that deactivates the measure (no more detour recommendation and toll reduction) 
> e.g. splitting percentage in use of Kennedytunnel vs Liefkenshoektunnel is expected to reach a certain threshold level. 


+ Identify legal constraints which may jeopardize data exchange between partners > to be defined by all parties collecting and 
exchanging data. 


* Define characteristics of Beta/Test Users which shall be addressed to test the service > to be defined by all parties (e.g. 
commuters travelling from A to C via Kennedy Tunnel). 


* Pre-condition for SP's and users: Traveller intended to use Kennedytunnel, prior to getting incentive. 


Figure 25. Pre-conditions ONTF Antwerp 


Post-conditions - CM4 


Post conditions: state of the system at the conclusion of the use case execution. This 
description includes minimal guarantees (what must happen even if the actor’s goal is not 
achieved?): 


* Rewarding conditions should be taken into account by the PSP's routing algorithm. 
* Benefits 


— For road authority: better traffic distribution __ , p os , 
— For service provider: additional information to improve routing and end user service, additional revenue from road authority 
— For traveller: reduced travel costs, improved information 


This description includes success guarantees (what happens when the actor’s goal is 
achieved?): 


* Road users have changed their routes. 
* Improved distribution of traffic over 2 river crossings when toll is lowered/suspended for certain users. 
e Valid business model is identified. 


Figure 26. Post-conditions ONTF Antwerp 


The last step is to sequence diagrams, which can help visualise the flow of information and 
chain of interaction between actors and services. 
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USER 


Reguest route Reguest route 


- Monitor traffic 
Trigger 3 Monitor traffic : Calculate routes 
event Activate measure : 


Distribute message Distribute message 


* Monitor traffic Distribute 
: Define target levels rewarding 


+ & rewarding conditions conditions l p 
5 Provide route Provide route 


Provide followed 
routes Track route 


Validate imapct 
Provide reward 
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Figure 27. Sequence diagram ONTF Antwerp 


The sequence diagram and the system overview help to identify interfaces that need to be 
further elaborated in the discussion among the actors considering required data/signal, 
data formats and standards, security mechanisms, etc. 


Following the stepwise approach, as described in this section, the SOCRATES? partners 
were able to reach a common understanding of the business problem, align solution 
areas and KPIs and prepare the implementation phase in a way that reduced unforeseen 
obstacles and hurdles and guaranteed a smooth preparation of the solutions and pilots. 
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SOCRATES? paves the way for the next generation of traffic management. On the path 
ahead lay several concepts and opportunities, or generally speaking, enablers, which can 
facilitate or accelerate the concept of interactive traffic management. But there are also 
challenges, impediments and bottlenecks, which can delay or even hinder some of the 
envisioned goals. 


The enablers and bottlenecks can affect any traffic management solution during the 
preparation or deployment phase, either at pilot sites or in a European roll-out. Also, they 
will likely differ depending on the type of use case or local conditions. 


In the SOCRATES2.0 Activity 2 report'?, potential bottlenecks were analysed before the 
pilots took place and clustered into the following categories: 


e Data bottlenecks 

e Technical bottlenecks 

e Organisational bottlenecks 

e Business-related bottlenecks 
e Legal bottlenecks 

e Conceptual bottlenecks 


The initial bottleneck analyses can now be revisited based on the experiences and 
evaluation outcomes of the planning, deployment and operation of the concept at our four 
pilot sites. The project also provided a number of explicit enablers, such as the cooperation 
framework and the TMex concept (see Section 2). 


The next chapters highlight the lessons learned about selected enablers and bottlenecks. 
These lessons are also placed in the context of the broader idea in interactive traffic 
management and public-private cooperation. In this context, higher-level actions are 
determined for use outside this project, for instance in legislation or standardisation, and 
recommendations are given on how to handle the enablers and bottlenecks in future 
interactive traffic management activities. 





"3 Koller-Matschke, I. et al., 2018. Proposed Cooperation Framework & Bottlenecks, Deliverable of the SOCRATES2.0 project. 
https://socrates2.org/download_file/force/112/184 
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4.1 Data enablers & bottlenecks 





Accessibility of data 





In interactive traffic management, availability and exchange of data is one of the 
cornerstones for successful implementation. Relevant, respectively required data is 

often in the domain of various stakeholders. Specifying and agreeing on suitable terms & 
conditions for data exchange and usage while on the same time guaranteeing privacy and 
last but not least identifying sustainable and attractive business are key for successfully 
opening up the access to data sources and thus enabling “interactive traffic management". 


In SOCRATES?” the partners operated in a special, pre-commercial environment which 
removed the obstacles for data exchange. In other words, data exchange mechanisms 
between affected partners were planned and deployed within the pilot environments. 

Any arrangements for data provision were made via pilot specifications, especially via the 
intermediary concept. Due to this project-specific framework in place, the mutual trust 
between the involved parties and the introduction of the concept of a trusted intermediary, 
data could easily made available and shared amongst the involved stakeholders. 


Due to these specific circumstances it was neither required to elaborate appropriate 
business models nor to setup specific terms & conditions for the data exchange. Still, in 
the Munich pilot site, the German National Access Point could be used as technical enabler 
for data exchange, including related and existing terms & conditions. Further, in the 
Amsterdam pilot site, the intermediary role Network Monitor was implemented and used 
as technical enabler for exchange of data. 


It has to be realised that such a high level of data accessibility, as demonstrated in the 
SOCRATES? pilots, cannot be taken for granted, especially when there is a situation 

with no funded project. The pure provision of digital data, such as Traffic management 
measures, can be mandated by law, as already done by EC Delegated Regulations", 
However, such regulations will most-likely not cover all data, as required in complex Traffic 
management schemes, as demonstrated in SOCRATES?°. Thus, data accessibility, sufficient 
to allow interactive traffic management, cannot be guaranteed this way. It can neither be 
guaranteed, that such data is reused and integrated by all relevant partners of interactive 
traffic management. 


In contrast, we have shown in SOCRATES2.0 that data accessibility, sufficient to allow 
interactive traffic management, relies on mutual agreements and agreed interactions 
between affected partners. This has been concretised in SOCRATES? via cooperation 
models, and should be further elaborated as business models (see Section 5.3.). 





14 There is an obligation to provide some traffic management-related information by road authorities, using the DATEXII standard 
and a National Access Point, however only for certain parts of the road network. See: European Commission (2014). Commission 
Delegated Regulation (EU) 2015/962 of 18 December 2014 supplementing Directive 2010/40/EU of the European Parliament and 
of the Council with regard to the provision of EU-wide real-time traffic information services. 
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Those aspects still need to be addressed for future “interactive traffic management” 
solutions. 


Availability of data 





The implementation of some innovative aspects of interactive traffic management will not 
be attainable without relevant data being available. 


First, availability refers to data and information that makes digitalised Traffic management 
possible, i.e. any data about the traffic state (e.g., traffic volumes and speeds), triggering 
conditions (e.g., events, air quality) and corresponding Traffic management measures. 
Such data and information usually lies in different hands and in different formats. 

Within SOCRATES”, this was not a big issue, as the majority of data, as required for the 
SOCRATES”? use cases, was already available or made available by project partners, e.g. by 
digitalising new management schemes. 


However, as stated above for data accessibility, this cannot be taken for granted in any 
circumstance. With the aim of a large-scale roll-out of interactive traffic management, data 
and information about any transport infrastructure elements, and from any corresponding 
authorities needs to be available. This is also true for the availability of data (e.g. speed 
and volume) for the lower road classes and rural areas. Looking at medium- and small- 
size municipalities in Europe, traffic management related information is sometimes 

not digitalised sufficiently, or even not existent. In this context, a stronger support and 
investment into the technological advancement of the transport network and related 
authorities, e.g. via sensors and TMCs, is an ongoing field of action. Several follow-up 
projects tackle this issue’. 


Availability of data is also relevant for impact-driven approaches in which the contribution 
of the involved stakeholders (public, private and end users) to the successful operation 
shall be not only measured but also incentivised. This relates to data and information 
about efficiency and reaction of road users, regarding Traffic management measures. 
Such data is a very innovative aspect in SOCRATES?°, and requires special attention. 


To measure the performance of the single services contributing to an interactive traffic 
management solution, information is required such as: 


e the number of end users reached with a specific service, or 
e the number of recommendations accepted by end users, allowing insights into follow-up 
behaviour. 





15 For example, the new SATURN project in Germany aims to digitalize Traffic management measures in smaller municipalities, 
and provide such information to service providers in a harmonized way via the National Access Point. See:https://www.bmvi.de/ 
SharedDocs/DE/Artikel/DG/mfund-projekte/saturn.html 
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Based on such information, it will be possible to measure: 


e the effectiveness of the system, 

e the contribution of stakeholders and 

e the behavioural changes / willingness to adopt of individuals, thus constituting a 
feedback loop. 


Within SOCRATES”? this kind of insights was barely available, e.g. via limited data evidence 
by the Evaluation activity, as this touches the very sensitive interaction (GDPR) between 
service providers and their end users. 

However, new impact-driven business models / incentive schemes may require the 
gathering and exchange of this information. The partners of SOCRATES?” see this topic as 
relevant for future activities, e.g. looking at frameworks and mechanisms to make end- 
user-based and service-provider-based data available in a wider scale. 


Quality of data 





When acquiring data from external parties, it is not always clear if the data meet the 
requirements of the data consumer. Quality of data is rarely systematically assessed and 
transparently documented. The reliability and safe operation of services contributing to an 
“interactive traffic management” solution may be negatively impacted by poor or varying 
data quality. This may lead to erroneous information within the information chain, but also 
to false recommendation to the end user which may have a negative impact on the user 
acceptance and consequently on follow-up rates and finally on poor system performance. 


SOCRATES? neither elaborated new solutions for data quality nor excessively used 
existing data quality frameworks. There are some frameworks to describe quality criteria 
and minimum quality levels'®, however, they need to be specified and validated in local 
and project-specific environments. Nevertheless, the project partners learned that having 
commonly accepted metrics to describe data quality will not only reduce required efforts 
when working with similar or overlapping, and sometimes duplicate data coming from 
various sources, but also help to make the value of data from various sources comparable. 
This may be an important aspect when introducing impact-driven business models. 


SOCRATES?° recommends to further work on agreed and uniform data quality assessment 
procedures going beyond the existing approaches and being more suitable for “interactive 
traffic management” solutions. Such procedures and agreements should be commonly 
established with all related parties. A concrete proposal is given in the follow-up plan (see 
Section 5.4). 


Data security 





A security infrastructure, assuring integrity and privacy of vehicle data, has been proposed 
by C-ITS stakeholders, but is not in place yet. Within the SOCRATES?° project state-of-the-art 
procedures has been used. No further effort was put into the topic. 





16 For example, there is a EU-funded activity about ITS Data Quality, which publishes agreed and uniform Quality Frameworks for 
specific ITS domains. https://www.its-platform.eu/highlights/update-eu-eip-quality-package-srti-and-rtti 
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Data standards 





To enable smooth exchange of data the use of commonly accepted standards is 

a prerequisite. Within the SOCRATES?” project DATEX Il, DVM Exchange as well as 
OpenLR were used as foundation and even extended, to meet the requirements of the 
implemented use cases. 


The project partners worked on the extension of the standards to exchange Traffic 
management Plans and Environmental Zone information, in close cooperation with the 
responsible bodies for standardisation. 


Major observations and challenges faced were the following: 


e Using a harmonised data standard, as s baseline for data exchange in Traffic 
management, is considered a prerequisite for interoperability and scalability across 
users and deployments. In certain cases, a DATEXII profile could be transferred from 
one SOCRATES”? pilot site to another. This saves deployment efforts and increases the 
acceptance by (potential) data re-users. 

e However, a standard which is not commonly used is hard to work with. In this context, 
usage guidance and harmonisation is on ongoing issue, by clearly defining the syntax 
and semantics of the modelled information. For a further roll-out of interactive traffic 
management, fostering such harmonisation across Europe is key to tackle the issue. 

e OpenLR as standard for location referencing is an issue for many parties as they lack 
in expertise in using it. Still OpenLR as a map-independent standard does not solve all 
interoperability issues, as the usage of different maps may lead to misinterpretation 
when exchange data. 

e While DATEX II is meant to be the standard for exchanging traffic related data between 
backends, there is only a limited number of experts available. We learned that DATEX 
ll is not self-explanatory, when using it, and even more complicated to handle, when 
developing an own, DATEXII-based data model. This is hindering not only smooth 
implementation by the different stakeholders, but also put obstacles in the discussion 
between the parties. 


Recommendations for future projects with regards to standards are the following: identify 
required standards, if possible, before the beginning of the project and make sure, that 
required expertise and knowledge is available either at the parties involved, or can be 
made available through external parties. In case there is no mature standard available, e.g. 
for an innovative use case, think about how to efficiently advance with an existing standard, 
or even propose a new one. In this case, be in touch with data standardisation bodies 

and data harmonisation activities in Europe, to make sure your approach is sustainable 
and compatible with ongoing developments outside your project. It is also strongly 
recommended, that the DATEX Il community takes responsibility for harmonised usage of 
the standards. The existing dialects prevent smooth scalability of data exchange. 
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42 Technical enablers & bottlenecks O 


S 


Existing TMCs, especially the older ones, have gaps when it comes to communication, 
interfaces in correlation with external actors. Integration of new data/information and 
processing of the latter is also a challenge mainly due to old software architectures in 
place. In the worst case this may impact the Europe-wide roll-out of interactive traffic 
management solutions or lead to redundant systems where “old” and “new” solutions run 
in parallel. 


Compatibility with TMC legacy systems 





In pilot projects the aspects mentioned above do not play such a big role as they will be 
usually worked out within the project frame. 


In SOCRATES”, the public and private parties were partly able to overcome the obstacles 
mentioned above. Within the pilot sites Amsterdam and Antwerp, the use cases 
implemented required an interaction between public TMC and private services. This 
connection was actually realised by the help of intermediary roles. 


A major observation was that using existing standards help overcoming connectivity issues, 
as it is in the interest of today’s TMCs to interact in a standardised way with 3rd parties. 


Recommendation for future projects: creating an overview on existing interfaces to the 
legacy systems at the very beginning, a detailed list of required interfaces together with an 
elaborated view on future processing chains and required capabilities for each identified 
interface will lead to a smooth implementation and roll-out of new services and solutions 
enhancing the existing traffic management capabilities. Involving the people working at 
the TMC from the early beginning is also beneficial, as they can provide insights into their 
operational tasks and workflows which shall be considered when implementing a new 
solution. 


Market penetration of connected vehicles 





Today the penetration rate of connected cars, services interacting with traffic management 
and TMCs with interfaces to connected services is still very limited. This leads to hardly 
measurable impact of interactive traffic management solutions and is thus a barrier for 
promoting the introduction of such solutions. 


Also, product life cycle management from connected vehicle services need to be 
considered as it needs a significant run-in period before new services can be integrated 
into a commercial offering. In SOCRATES2°, we saw how this can impact the development of 
a solution and ultimately lead to the decision, that a solution cannot be implemented at all. 
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Within SOCRATES? pilot site Amsterdam and Antwerp were able to recruit a large amount 
of pilot users using mobile as well as in-dash connected services. Nevertheless, this 
number was still too small to measure impact. 


Recommendation for future projects: for large-scale pilots start as early as possible with 
promoting the upcoming services and check on the one side for suitable stakeholders on 

a regional level but also with global players with interest in interactive traffic management. 
Implementing a professional campaign may support the recruitment of a sufficient number 
of pilot users required for evaluating impact of interactive traffic management solutions. 


Cellular communication networks 





Connectivity is a prerequisite for connected services. All services require full availability 
and network coverage. Within SOCRATES?? no stakeholder from the telecommunication 
industry was involved. But within the scope of the project all use cases could be 
successfully implemented and tested using the existing infrastructure. 


SOCRATES?” did not further investigate the topic, but recommends considering the 
communication infrastructure aspects from the early planning stage on as it may become 


an issue especially in non-urban environments. 


Advanced traffic management algorithms 





In some cases, existing TMCs are still isolated systems, including proprietary sensor data 
and actuators, and (automated) algorithms triggering traffic management measures. New 
solutions of interactive traffic management will require, respectively use, new sensors and 
data sources as well as integrating new actuators. To consider these aspects the existing 
algorithms have to be at least re-designed and re-validated. Even an enhancement of the 
traffic theory behind the aforementioned algorithms may be required. 


Within SOCRATES?! pilot site Amsterdam several algorithms with focus on traffic prediction, 
load balance and free flow were implemented and tested to facilitate a proactive 
management of traffic measures. But those algorithms were not based on new sensors or 
data sources. 


In all pilot sites connected services from private service providers were used to 
complement the set of existing actuators to influence traffic and travel behaviour. It was 
demonstrated, that technically the new actuators can be integrated into interactive traffic 
management solutions. However, due to limited number of pilot users, a quantitative 
impact of those new actuators could not be measured. 


For future activities, the SOCRATES2° partners recommend to have a closer and probably 
more research-focused look into the added value from traffic theory and algorithms. Also, 
the integration and impact of new actuators as part of interactive traffic management 
solutions can be further. 
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4.3 Organisational enablers & bottlenecks 





Consensus on cooperation models 





One of the challenges is to identify and define a viable cooperation model that does 
not only fit to the solution(s) anticipated, but also needs to be accepted among the 
participating partners for each deployment of interactive traffic management. 


The SOCRATES?° partners agreed, that a cooperation model should add value for each 
participating party. In SOCRATES° we call this the win-win-win concept. Within the project 
we learned, that the win-win-win is not easy to find. Altogether, the SOCRATES? partners 
see a risk in sustainable deployment, as long as a proper business model is missing (see 
Section 4.4), indicating clear impacts for each partner. 


Within the SOCRATES?? project several cooperation models were elaborated, discussed 
and successfully implanted in the pilot sites. Three categories of cooperation models were 
identified. They mainly differ in the level of commonality. The parties working together 
agree to: 


e The first model is on exchanging data on a voluntary basis using an agreed standard 
protocol. This model is suitable for services aiming at spreading information without 
the need for further enrichment of the data or coordinated actions with main focus on 
maximum information coverage for the end users. 

e Inthe second model the participating parties operate on a common situational picture. 
This approach will eliminate the risk of contradicting / unaligned information provision 
to the end user which may still happen in the first model. Still each party continues to 
independently optimise and operate its own end-user services. 

e Finally, the most ambitious model is the third one. It not only requires a common 
situational picture but does also aims for coordinated actions of the public and private 
parties involved to actually come close to a global optimum without completely ignoring 
individual needs. 


All three models were applied to different use cases at the four pilot sites. Feedback and 
recommendation from the pilot sites is to start identifying the most suitable models as 
soon as possible when planning / tendering a new project as some of the models will not 
only require additional roles but also additional parties fulfilling the additional roles. 


When identifying and selecting the appropriate cooperation model, it is also recommended 
to keep the added value for each party involved in mind. As already mentioned at the 
beginning of this section, in SOCRATESZ? we call this the win-win-win for public and private 
stakeholders as well as the end user. 


There are no obvious solutions for such win-win-win. Incentives and rewards are assumed 


to be part of the solution. The enabler is, that we experienced that road users are willing 
to comply with traffic management related advice, when the right conditions apply and 
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that service providers are willing to provide reach and impact to the road authorities. 
On the other hand, a bottleneck is that the latter are not automatically willing to pay for 
such services as the gained impact is unclear and required funding is difficult to get. Due 
to the local setup of the Antwerp pilot site, SOCRATES? was not only able to showcase 
value of an incentive-based solution, but also how an appropriate business model can 
look like. But a win-win-win is not per se a monetary value, but can also be an increased 
user base, improved service offering (better data coverage) smarter route or destination 
recommendations 


Further, the precondition to realise the win-win-win is the digitisation and accessibility of 


required data and information, and supporting mechanisms such as National Access Points 
(see Section 6.3). 


4.4 Business enablers & bottlenecks 





Return of Invest 





For public and private parties, investments in technical infrastructure, additional data 
sources or services extensions need an economic justification. Not only for private parties 
the identification of sustainable business models is crucial for the implementation of 
interactive traffic management solutions. 


Therefore, SOCRATES? put strong emphasis on identifying the win-win-win for all involved 
parties (public, private and not to forget the end user) already in the pilot-preparation 
phase. It was agreed by all parties, that without a convincing win-win-win situation the 
willingness to invest, respectively adopt will be rather low or not sustainable. 


Several approaches were discussed: 


The most promising approach for the more complex cooperation models seems to be an 
impact-driven approach. In this model, all involved parties are remunerated based on their 
contribution to achieve commonly agreed targets. Due to the complexity of this approach. 
as well as the so far missing skills to elaborate at least a basic model, SOCRATES?* did not 
come up with an impact-driven business model. 


Still, SOCRATES2° was able to develop a new model based on a publicly funded incentive 
scheme. This model was successfully applied at the Antwerp pilot site for the Optimising 
Network Traffic Flow use case. The very specific local conditions of the Liefkenshoek Tunnel 
made such a model possible. 


Exchanging data, as a third approach for a business model, was also implemented within 


SOCRATES?°. Nevertheless, it needs to be stated, that this was possible due to the specific 
contractual situation of the project. 
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Last but not least, the sharing a common view presents a specific approach, where 

all parties have access to the same information and can distribute this information to 
their customers. The result is a uniform state of knowledge at the end-user level. The 
Environmental Zone use case, as implemented in the Amsterdam pilot site, demonstrated 
the added value of information provided by the road authorities, incorporated into the 
applications of the private service providers and thus maximising the reach to the road 
users. 


The SOCRATES? partners have identified the missing of appropriate business models as 
a main obstacle for the for the successful introduction of interactive traffic management 
solutions. To overcome this gap further work is needed. The challenges identified and to 
be addressed on follow-up activities: 


e What is the value of data, how can the value be measured and how can data sharing 
models look like? 

e To which level (in terms of time and volume) is public funding needed to enable first 
implementations of interactive traffic management? 

e How can impact-driven business models, to improve road safety, efficiency and 
sustainability, look like? What are appropriate KPIs and how can they be measured? 
What is the value a service can deliver and how can that be quantified? 

e Isa trusted entity required to enable interactive traffic management solutions and 
respective cooperation models, and how do they fit into the business model? 


4.5 Legal enablers & bottlenecks 





Privacy concerns 





Within the SOCRATES20 activities, we did not focus on data protection and privacy topics 
which was in retrospective a missing aspect for subsequent project activities. 


When it comes to data privacy the SOCRATES?’ partners learned quickly, that GDPR measures 
prohibit service providers in measuring the service usage and impact as tracking of people 
and their behaviour is a very sensitive topic and needs the consent of the end user, which 
shall not only include the rights to collect the data, but also to gain insights and share 
aggregated conclusions. 


Within the SOCRATES?! deployment, neither the means to collect such required data, nor 
the appropriate consents could be implemented during the duration of the project, as this 
requires good and exhaustive legal preparation. 


It is recommended to further elaborate on the topic in the future and have required consent 


in place, before starting projects in which information on individual user behaviour is required. 
This will not only increase the user acceptance, but also limit the risks for project execution. 
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The SOCRATES?” partners agree that finding a suitable approach for the topic will be a 
prerequisite for the further elaboration of impact-driven business models. The expectation 
of road authorities is, that they get transparent information for what impact they actually 
spend their money. 


Liability 





Faulty or inaccurate data or information as well as malfunctioning systems can have severe 
impact on service execution in interactive traffic management which may lead to legal and 
liability implications for the actors involved; in the worst case resulting in complicated legal 
trials and possible high costs. This is especially important for use cases providing legally- 
binding information. 


Within the Speed and Lane Advice use case in the Antwerp pilot site, information displayed 
at gantries along the road was delivered to the drivers using a mobile app. In such case, 
users of this app should be aware that the speed and lane advice displayed at the gantries 
do overrule the information presented in the application. 


Further, we were faced with liability in context of the technical chain. However, acceptable 
latency and down times of the system did not lead to any issues here. Therefore, we 
recommended focussing on the quality of the data and impact on the services. 


Besides that, SOCRATES?” did not further elaborate on the topic. However, the liability 
aspect needs further elaboration and is expected to be a complex topic, as it is involving 
multiple public and private stakeholders and may include several communication channels 
with different responsibilities. 


Data ownership: 





Ownership of data may become a difficult topic in the eco-system of interactive traffic 
management. Questions like who owns the data (and is liable for the data) may become 
blurry if several parties accept to let a 3rd party aggregate their data to create a common 
view. A legal framework may be required to avoid misunderstandings and take care of the 
liability and rights to further share the content. 


Within SOCRATES? the roadworks use case was implemented in pilot sites Amsterdam, 
Antwerp and Munich and in all implementations several parties agreed to aggregate and 
share the data. This was possible because of the specific project setup, but still required 
in some cases additional legal agreements. It is an open question if under different frame 
conditions the topic of aggregation and sharing would have been solved as smoothly. 


It is strongly recommended to further elaborate on that topic and find solutions suitable 


for interactive traffic management as otherwise it may jeopardise the successful 
implementation. 


66 


I 
` 


e 
4.6 Conceptual enablers & bottlenecks = = 
` 


8 
= 
v 


Major conceptual aspects arise from the project approach in SOCRATES?®°, in particular the 
elaborated building blocks and approaches to the various pilot demonstrations. 


Common building blocks and approaches 





First, many alignments and agreements about the building blocks and approaches were 
made ahead. Harmonised building blocks were elaborated as a shared vision, cooperation 
models, TMex, evaluation techniques etc., see Section 2. Further, some harmonised 
approaches for the pilots deployments were defined, to help to find consistency and a 
common understanding across all pilot deployments. To support this, general templates 
(e.g. functional design templates) and a common wording to describe certain aspects (e.g. 
for the intermediary roles) were used. This harmonisation approach indeed resulted in 
increased efficiency, so not every pilot had to define its approach from scratch. This also 
supports scalability and transferability, being overarching goals of SOCRATES2°, as building 
blocks and the individual approaches were aligned, and can be most-likely be reused in 
future deployments. 


In general, common approaches to ITS projects are handled via ITS architecture activities in 
Europe. Such activities work towards integration and harmonisation of individual ITS. Basic 
building steps of such activities are guidelines and agreements for the creation process 

of individual ITS architectures”. One core philosophy of these activities is to provide “ITS 
reference architectures”, which include general design descriptions, examples and patterns 
for a specific ITS domain. These “ITS reference architectures” can then be transferred to 
concrete architectures of real ITS-services. 


In SOCRATES2*, we followed a similar approach. The analogy is that each (pilot) deployment 
of interactive traffic management is an individual ITS, which eventually also needs to be 
integrated and harmonised. An architecture creation process is then the approach for a 
specific deployment. By defining common building blocks and approaches, we already 
provided some common ground, which should be exploited and maybe advanced in 
future deployments. An idea is to provide an “ITS reference architectures” specifically 

for the interactive traffic management concept, based on our SOCRATES?” work. This 
would add further aspects on governance, organisation and technical levels for individual 
deployments, and eventually foster some validation and acceptability for European 
stakeholders, when interested in the SOCRATES?! concept. Such idea may be intensified by 
a future, EU-funded projects. 
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For example, the current FRAME NEXT project aims to provide “methodologies and tools that make a modern ITS architecture 
attractive and appealing for its users”. See: https://frame-next.eu/objectives/ 

In Germany, there was already an attempt to provide an “ITS Reference Architecture” for the data exchange between urban 
road authorities and navigation providers. However, this work is tailored to the German situation and conventional traditional 
traffic schemes, whereas SOCRATES?” goes beyond this. See: https://fops.de/aktuelles/2020/city2navigation/ 


oo 
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As a last note, even if a harmonised design approach is recommended across all pilots, 

it is still crucial to consider and respect local conditions as well as individual perspectives 
of partners. In SOCRATES2°, this has been achieved by an initial pilot site inventory and 
reflected as a precondition for each pilot design. The respect for local conditions must be 
equally allowed by any “ITS reference architectures”. 


Need for project flexibility and proactive project management 





While many details about the SOCRATES? approach were defined at the beginning, 

many changes had to be made during the project, to account for changing circumstances 
and newly arrived needs. About changing circumstances, most-relevant was the Corona 
pandemic, which led to a re-visiting of the demonstrations goals, e.g. in terms of evaluation 
users and traffic loads across the pilot networks. Further, some partner roles changed 
throughout the project, resulting in new assignment between goals and partners. About 
the newly arrived needs, some additional agreements had to be taken on a cross-pilot 
level, which were not completely resolved before the pilot deployments. Such additional 
“pilot overarching activities” related to alignment and concretisation of topics such as data 
architectures, cooperation models, and beta-users. 


The lessons-learned in SOCRATES2.0 is that a proactive project management with 
supervisory powers plays a crucial role to handle any unforeseeable circumstances. 
Similar management skills should be carefully laid down in the project preparation for any 
deployment, maybe allowing agile processes in the project development phases, or be 
considered by contractual regulations by the funding bodies. 
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5. FOLLOW-UP PLAN 


. 





SOCRATES2° 





SAFE GREEN 


5.1 Follow-up focus areas 


As summarised in the previous sections, SOCRATES?” provides basic frameworks for and 
demonstrated first experiences with our interactive traffic management concept. It is 
evident that a further European deployment depends on further actions involving a wider 
stakeholder community. Throughout the project, liaison with other European initiatives and 
external communication and dissemination of the results were very important in creating a 
maximum of support for our interactive traffic management concept. 


One of those activities is to address topics that require further attention after the project. 
In particular, we need to formulate any outstanding issues and actions, to make the 
concept sustainable and fully accepted. Target groups are other relevant stakeholders, 
such as road operators, service providers, car industries, international organisations, 
legislator and regulatory bodies, and others. The topics that require further attention are 
summarised in the follow-up plan, as presented next. 


A first step is to identify relevant follow-up focus areas. This starts with a reflection on 
the three cooperation models, as detailed in Section 2.2, as well as on the maturity of the 
SOCRATES?*° concept, as elaborated by the Evaluation activity’. 


When elaborating and implementing these cooperation models in real-world environments, 
the aspects in the table below were identified as being crucial for follow-up activities. It is 
evident that the more advanced cooperation models have more follow-up areas. The follow- 
up focus areas outlined in the table are elaborated in the subsequent subsections. 





19 See the SOCRATES?” Final Evaluation report 
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Table 6. Follow-up focus areas 


Data standards: enhancement, harmonisation, 
knowledge building. (see Section 5.2) 
Alignment on map-independent location- 
referencing methods. (see Section 5.2) 


Further exploration of the cooperation 
framework. (see Section 5.3) 


Advancement of regulatory and legal 
frameworks for interactive traffic management. 
(See Section 5.5) 


Catalysation of future deployments of 
interactive traffic management. (see Section 
5.6) 


Alignment on and definition of data quality. 
(see Section 5.4) 

Alignment on and definition of service quality. 
(see Section 5.4) 

Identification of an operational model for 
intermediary roles. (see Section 5.3) 
Elaboration of a suitable governance model. 
(see Section 5.3) 


Elaboration of an appropriate and manageable 
(impact-driven) business models. (see Section 
5.3) 


Elaboration of a suitable tendering process. 
(see Section 5.3) 
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5.2 Data standards: Enhancement, harmonisation, knowledge building. 


As stated throughout the report, a common digital language is a crucial building block for 
communicating traffic management information between the various partners and enabling 
the interactive traffic management concept. This was concretised as harmonised data formats 
and interfaces, under the responsibility of the cross-pilot TMex activity (see Section 2.3). 


The TMex progress results were positioned within the European DATEXII group through 
the continuous participation of DATEX Il experts in the SOCRATES?” project. This interaction 
resulted in two aspects: 


e Anumber of concrete DATEXII profiles for the SOCRATES?! pilots were established in 
the frameworks of DATEX II. This was done by reusing and, where necessary, adding 
information items to the DATEX II data model. 

e The elaborated DATEX II profiles, including lessons learned about their usage, found their 
way into future DATEX II activities. This means the development of the overall data model 
will consider our elaborations. 


Overall, the interaction with the European DATEXII group was highly beneficial as they 
enabled data interoperability aspects to be considered from the start. In contrast, a stand- 
alone data format may have been easier to implement in our pilots, but would not have 
been as attractive to parties outside the project. However, we concluded that the DATEX 

IL harmonisation work within the SOCRATES? project should only be a small part of the 
puzzle within the wider scope and stakeholder landscape of a data harmonisation group. 


In particular, the elaborated DATEX II profiles are not yet mature enough to be deployed on 
a European scale, and further validations and enhancements are needed. In particular, we 
expect that new or enhanced specifications need to be defined, for example, for network 
optimisation or rerouting use cases. With added maturity, DATEX Il-based communication 
is expected to be even more efficient in the domain of interactive traffic management. 


While DATEX Il is widely promoted in the EU, it is applied differently from country to country 
and even from party to party (public and private) and sometimes even within parties. 

The lack of a heterogeneous usage was also identified as a bottleneck during our pilot 
deployments. Alignment is therefore needed of how to apply DATEX II profiles, for example, 
by means of supporting documents with a clear semantic description of model elements. 


Furthermore, DATEX II messages often contain geo references expressed through 

various location-referencing methods. Experiences gained during the SOCRATES?° 
deployments show how important it is to align methods across the many data use cases 
and communication partners. This would help avoid inconsistencies when interpreting 
georeferenced data and avoid post-processing of that data. OpenLR, as a map-independent 
approach, is promising in this context, but not commonly used. ALERT-C, as a pre- 

coded method for location referencing, is used more often, but does not cover all roads, 
especially in urban settings. As for DATEX Il in general, harmonisation is needed of location- 
referencing methods and support to users. 
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The major follow-up action needed here is for the DATEX II group to take on data- 
related harmonisation and support issues and any other activities with data standard 
aspects. The goal is to advance with the DATEX II specifications for specific interactive 
traffic management use cases, and to validate those DATEX II specifications under future 
deployments. A specific recommendation here is to consider the heterogeneous field 

of data partners, each with their different roles and expectations when using a data 
specification. Fostering further dialogue with partners would provide a solution. 


A situation where our DATEX Il harmonisation efforts could be directly transferred to 

a follow-up activity is the Environmental Zone use case. For this, contacts have been 
established with the European UVARbox project (see Section 5.6). Results and lessons 
learned were shared about the SOCRATES?! Environmental Zones pilot in Amsterdam. This 
is a best practice in terms of a follow-up action already in place. 


Another open issue concerning data standards is knowledge sharing and building. There 
are only a few DATEX Il experts who can help with harmonisation, specifically when 
specifying local deployments of interactive traffic management. This clearly shows that 
individual knowledge sharing and consulting is needed on the correct usage of the DATEX II 
framework for specific deployments. This would allow for highly efficient use of the DATEX 
ll information model, and for parties to take advantage of the ongoing standardisation 
process of the European DATEX II group. 


An upcoming European project in this context is NAPCORE, which, among others, will focus 
on the education of more experts in the field, addressing the mentioned lack of DATEX II 
expertise in Europe (see Section 5.6). 


5.3 Further exploration of the cooperation framework 





Towards a sustainable business model for the Coordinated Approach 





Based on lessons learned and experiences gained from four pilot sites, multiple business 
ideas emerged for the SOCRATES?! Coordinated Approach cooperation model (see Section 
2.2). The most innovative and promising examples refer to an “effort-driven business 
model” and “impact-driven business model", where the main goal is to create a common 
value proposition. These two ideas for business models are explained below as a guideline 
to foster business aspects for the Coordinated Approach cooperation model. 


According to Section 3.2, we structured the business growth process along the following 
three stages of maturity: 


e Piloting stage (e.g. what we did in the SOCRATES?! project) 


e Effort-driven business model stage 
e _Impact-driven business model stage 
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In the piloting stage trust needs to be built between partners before a cooperation can be 
effective. Learning and building trust for a sustainable cooperation are the main objectives 
in this stage. Otherwise, no immediate impact on public and private long-term goals can be 
expected. A short-term goal for this stage is to have a common understanding on required 
content, suitable cooperation model(s), experience and assets each party can bring to the 
table. The first iteration of this stage can be challenging and time consuming. But after the 
establishment of a first concept of the technical chain, later improvements or iterations 
will go faster. The intended procedure is to start with the piloting stage, then go to the 
effort-driven business model stage, and after that the impact-driven business model stage. 
However, depending on the complexity of the use case and number of partners, some 
stages can be skipped. 


Effort-driven business model stage 

The effort-driven business model stage empowers an already initiated or established 
cooperation (e.g. piloting stage). The goal would be a more effective cooperation, where 
some goals are met. It is advised to start with 100% public goals for the optimisation, to get 
a clear view of the benefits for the optimisation. Then the piloting stage can be revisited 
and improved based on lessons learned. 


Continue the cooperation 

Anyone can initiate the continuation of the cooperation; however, the road authority 
should orchestrate the cooperation. For the first iteration, a government is needed that 

is committed for a longer period. For private firms, the cooperation should be open 

and transparent. The cooperation must be open for newcomers, and existing partners 
should be free to leave the cooperation. In order to reach sustainable cooperation, a legal 
framework is needed for government spending and procurement and a level playing field 
for private companies. 


Some real-life impact 

Small impacts can be expected on public goals. There will be some impact on private goals, 
at least to cover the cost. On top of that, private service providers can explore additional 
business opportunities and can improve services for clients. New business opportunities 
are available for private trusted intermediaries. 


Emerging business model 

In the second stage, no big investments are needed from the government. Most upfront 
investments were part of the previous piloting stage. However financial reservations should 
be made to compensate service providers for their efforts in reaching public goals with 
private services. The main business case for private service providers is an effort-based 
reward for service requests. They receive compensation for showing messages to their 
users, regardless of the generated impact. There is no obligation for service providers to 
follow or accept the service requests. However, for a significant number of cases it would 
be in the service providers’ interest to accept the service requests. 
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Rewarding concept 

A smart rewarding concept was developed in the SOCRATES*° Amsterdam pilot with 
different tiers of rewarding making the cooperation flexible for new partners. In short there 
is an incentive (or reward) for everyone who participates. However, the fee rate differs 

per tier. The lowest fee (RO) is basically an encouragement to participate without legal 
obligations. The highest fee (R3) is related to proven impact. 


Table 7. SOCRATES? smart rewarding concept 


Piloting stage Effort-driven business | Impact-driven 
model stage business model stage 


RO - participate 
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Figure 28. Rewarding concept in the SOCRATES?! Amsterdam pilot 


Impact-driven business model 

This business model is mainly based on an exploration of expert ideas for future 
development. This model supports a sustainable cooperation for an effective and efficient 
execution of traffic management. The main goal of the cooperation is a common value 
proposition. All partners work closely together and maximise the added value for the 
whole chain. 
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Figure 29. Aspects of value proposition for the SOCRATES*° cooperation framework 


Continue the cooperation part 2 

Network wide traffic management is the next step in optimising the traffic flows after the 
optimisation of intersections and corridors. Network optimisation requires a fairly complex 
technical system, but also an effective organisational structure. In this section, we focus on 
the organisational aspects. In order to optimise the traffic flows on a wide road network, 
you need to organise a cooperation of partners for an extended period. You need to create 
a sustainable long-term framework that also provides focus for the long term and flexibility 
for the short term. 


It is again advised to start with public goals (less congestion, less emission, safer roads) 

as the common goals. This makes the revenue streams clearer and as such increases the 
willingness of partners to participate. Especially for the service providers, it is important to 
leave ample room for business opportunities without jeopardising the common goals. All 
intermediary roles can be conducted by both separate public and private partners. 


Business model found! But hard to reach? 

No investments are needed from the government for this stage. The main business case 
for private service providers is an impact-based reward (R3) for service requests. This 
means, service providers are compensated if their contribution to the common goals is 
proven. Service providers sell impact. Compensation depends on measurable impact. This 
creates an incentive for service providers to maximise impact (e.g. re-routes). It aligns the 
objectives of service providers with those of road authorities. Service providers can nudge 
or incentivise their users in order to increase follow-up behaviour and impact. Service 
providers are often better placed to create impact in a more effective or cheaper way, 
since they can target specific users and use their creativity (e.g. in gamification concepts). 
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Besides such ideas, business-relates aspects need to be deepened in follow-up initiatives 
together with new stakeholders. First, we feel that proper foundations for business models 
should be detailed out, with a focus on a multi-party cooperation with public and private 
partners in the traffic management domain. Among others, this relates to new procurement, 
contractual and rewarding schemes. Based on that, the value of such integration needs to be 
further demonstrated, with new use cases and experiences, in order to gain more insight on 
the win-win-win and to further elaborate on the business perspective. 


Results 

A strong alignment of private and public services can be realised together with TMCs. As 
such, a large impact can be expected on public and private goals, and traffic management 
can become more cost-efficient and effective. There are also plenty of opportunities for 
private, trusted intermediaries to add value to the chain. 


The role of NAPs in facilitating data cooperation 





Data exchange is a basic functionality of the SOCRATES*° Cooperation Framework. It is 

a cornerstone in all of the three elaborated cooperation models (see Section 2.2). Data 
exchange implies at least some effort on the part of the communication partners: data 
must be made available, accessible and reusable. Whereas for the SOCRATES?” pilot 
deployments, those efforts were covered by the project resources. The question now is 
how to lower those efforts for non-project situations, especially situations with evolving 
data ecosystems and perhaps even where the communication partners are not yet known. 


One well-known approach to this is the National Access Points (NAPs). NAPs are digital 
interfaces that make ITS data accessible for a wide range of data users. They are triggered 
by the European legal framework on ITS, the EU ITS Directive and the corresponding 
Delegated Regulations? NAPs can ease data exchange by establishing a central many-to- 
many data interface (see below). So, NAPs are considered a crucial digital building block 
when establishing a uniform mobility data ecosystem in Europe for crossing borders, 
transport modes and responsibilities”. 





20 See. https://ec.europa.eu/transport/themes/its/road/action_plan_en 
21 Jorna, R., et al., 2017. National Access Points: Challenges for Success. Presented at: 25th ITS World Congress. September 2018, 
https://eip.its-platform.eu/activities/monitoring-and-harmonisation-national-access-points 
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Concept of data exchange without a National Access Point 


DATA SUPPLIER X DATA USER 1 


DATA SUPPLIER Y DATA USER 2 


DATA SUPPLIER Z DATA USER 3 


DATA SUPPLIER X DATA USER 1 


DATA SUPPLIER Y DATA USER 2 


DATA SUPPLIER Z DATA USER 3 


Concept of data exchange with a National Access Point 
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Figure 30. Concept of data exchange without a NAP (left) and with a NAP (right) 


The concept above allows for a combination of data from multiple sources, creating 
new opportunities for end-user services, also for the domain of traffic management. 
Such multi-source environment is also a baseline for the establishment of NAPs”. 


Several new NAP data connections were established for the SOCRATES° deployments. 
One example concerns the data feed from the Bavarian Road Authority on the German 
NAP, which distributed service requests for the Smart Destination use case at the Munich 
pilot site. The data offer was not only available for the service providers involved in the 
project, but is now also available for any interested data users. This example shows how a 
NAP can facilitate the Exchanged Data cooperation model even beyond the project. 


Regarding this example, the German NAP not only enables pure data exchange (the basic 
function mandated by the EU regulation), but also gives the data supplier some control 

by supporting contractual relationships with data users. This helped strengthen the trust 
aspect within SOCRATES”. Furthermore, NAPs could also serve many other functions in 
future scenarios. In fact, there are discussions about features of the German NAP that 
could even support the other two cooperation models, for example, via data apps attached 
to the NAP, such as allowing data fusion and other data processing. 





2 Aifandopoulou, G., et al., 2020. National Access Points for Intelligent Transport Systems Data: From Conceptualization to 
Benefits Recognition and Exploitation, Computer Science - Computers and Society, October 2020, https://arxiv.org/ftp/arxiv/ 
papers/2010/2010.12036.pdf 
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According to SOCRATES?! understanding, a NAP can facilitate the more advanced 
cooperation models, when it fulfils at least one Network Monitor task (e.g. central data 
distribution of unique and/or trusted data, enrichment of data, data fusion or prediction). 
This way, a NAP can contribute to the SOCRATES° Cooperation Framework, depending on 
the NAP system capabilities. 


Altogether, we believe NAPs should be considered a basic building block for future 
deployments of interactive traffic management. The main argument for this is that it can 
ease data exchange between communication partners, and foster scalability through 
many-to-many data interfaces. 


However, there are still some open issues regarding the current capabilities and 
efficiencies of the individual NAPs. 


In theory, the scope of NAPs also includes traffic management related information, 
including static and dynamic traffic management plans and measures. The EC Delegated 
Regulations stipulate that such information should be provided by corresponding data 
suppliers, such as road authorities, and be considered by data users, such as service 
providers. 


Looking at the current NAP practice, however, shows an inconsistent data landscape across 
Europe in terms of data coverage, data standards and data quality. This is especially true 
for more advanced data categories, such as traffic management related information. There 
are only a few road authorities who provide such information in NAPs in a dynamic and 
harmonised manner. 


In this context, further efforts are needed to enable potential data providers to provide 
traffic management related information via NAPs in an efficient and harmonised way. 
This would involve not only defining harmonised data formats (see Section 6.2), but also 
establishing the technical and organisational prerequisites to facilitate data provision in 
the first place. This includes the digitalisation of traffic management measures as such, 
and technical tools to make data digitally available, especially for smaller road authorities. 
These prerequisites need to be tackled first before NAPs can be applied on a wider scale 
for interactive traffic management. 


As a follow-up, further enhancement is needed of the capabilities and efficiency of data 


provision via NAPs. Aspects such as these will be addressed by the future EU-funded 
NAPCORE project (see Section 5.6). 
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Applying the concept of cooperation models for automated driving 





Whereas the approach of interactive traffic management, as initiated and demonstrated 
by SOCRATES2*, relies on today's technologies, the project approach also anticipates future 
technology scenarios, such as Cooperative, Connected and Automated Mobility (CCAM). 

In such scenarios we expects an increasing connectivity and automation. This implies an 
increasing integration of the elements of the transport system, so a systematic approach 
to cooperation between elements seems evident. The question is whether the SOCRATES??? 
Cooperation Framework with its three cooperation models, as introduced in Section 2.2, 
can also be applied or integrated into the CCAM domain. 


In automated driving, which is a prominent use case of CCAM, systems are designed to 
operate under certain conditions, often called Operational Design Domains (ODDs). These 
are specified by the OEMs, and decide when, along a specific route, an automated driving 
mode is permitted or applicable. ODDs depend heavily on the infrastructure conditions, 
including physical and digital prerequisites of the infrastructure. These conditions are 
often called Infrastructure Support for Automated Driving (ISAD). ISAD indicate which 
infrastructure-related conditions relevant for automated driving functions can be expected 
by vehicles in the currently traversed road section. These can be physical features, such as 
the nature of lane markings, or digital features, such as V2I services. Both ODDs and ISAD 
can be classified”. 


From a traffic management perspective, there may be a need to control the presence and 
lack of presence of specific ODDs for specific situations, called ODD management. Imagine 
an incident location, spotted by a TMC, which needs to be instantly communicated to an 
automated vehicle to deactivate the automated functions. The ‘end locations’ of ODDs 

(i.e. locations where automated driving mode is switched back to manual) may also be 

of interest for traffic management, as ODD endings can provoke so-called minimal risk 
manoeuvres, and thus prevent risky driving behaviour. Lastly, in more advanced scenarios, 
a remote supervision of entire fleets, such as robotaxis, maybe be an interesting aspect for 
traffic management. 


For all these technological scenarios, different cooperation scenarios can be defined for the 
interaction between automated vehicles, the traversed infrastructure and network-related 
traffic management. Some first attempts have been made for an analogy between the 
three SOCRATES?? cooperation models and the above CCAM scenarios” (see below). 





23 Aigner, W. et. al., 2019. Vehicle fleet penetrations and ODD coverage of NRA-relevant automation functions up to 2040, 
deliverable of project: MANTRA: Making full use of Automation for National Transport and Road Authorities - NRA Core 
Business, CEDR Transnational Road Research Programme, https://www.mantra-research.eu/wp-content/uploads/2020/03/ 
MANTRA_Deliverable_D2.1_1.0.pdf 

24 Kulmala, R., 2021. Traffic, fleet and ODD management for highly automated vehicles. Presentation at: Third European 
Conference on Connected and Automated Driving, April 2021, https://www.connectedautomateddriving.eu/wp-content/ 
uploads/2021/04/EUCAD2021_D3_BO2_Risto-Kulmala.pdf 
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Figure 31. Analogy for SOCRATES? cooperation models and scenarios in Automated Driving 


This analogy builds on the concept of data exchange between road operators and vehicle 
fleets, by exchanging, for example ODD and/or ISAD attributes related to a specific situation, 
a specific network element or a specific vehicle. Such exchange may be advanced to a 
shared view of automated vehicle capabilities versus road conditions and infrastructure 
classification. The shared view is the stepping stone towards a Coordinated Approach for 
(autonomous) fleet and traffic management, and conserves good quality of service for 

both sides while reducing the risk of network degradation which is often associated with 
unmanaged (autonomous) vehicle fleets. In this sense, the same three-level approach of 
cooperation models seems applicable for technological scenarios in automated driving. 


Another, similar analogy is found in a correlation between the well-known automation 
levels (SAE J30162°) with a pre-definition of so-called cooperation classes*®. According to 
this approach, cooperation is crucial for automated driving, for safety and other reasons. 
The context of cooperation classes may differ, as they focus on machine-to-machine 
communication functions, not the organisational superstructure, as in the SOCRATES?° 
Cooperation Framework. However, the stepwise cooperation approach, as defined in 
SOCRATES?, can also be found here. 





25 See: https://www.sae.org/standards/content/j3016_202104 
26 Dopart, K., 2020. U.S. DOT Cooperative Driving Automation Research, Presented at: SIP-adus Workshop 2020, November 2020, 
https://www.sip-adus.go.jp/evt/workshop2020/file/cv/07CV_04_Dopart.pdf 
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Altogether, the SOCRATES? legacy on the cooperation models should be further exploited 
by stakeholders in the CCAM domain, as already done by SOCRATES?! partners MAPtm 
and BASt. This exploitation should take a deeper look at applicable cooperation concepts 
in CCAM, by first elaborating corresponding cooperation frameworks and then specifying 
them in technical and organisational terms, as previously done in SOCRATES2*. This is 
currently also being explored by ongoing research projects”. 


5.4 Alignment and definition of service and data quality 





Similar to the data standards (see Section 5.2), there is an evident need to align and 
define (minimum) levels of service and data quality. This is partly because multi-actor 
environments, as envisioned by SOCRATES?*, rely on a certain level of agreement on 
what data and services should look like to make a data-based cooperation efficient and 
sustainable. 


In the context of data quality, we talk about certain characteristics of information items or 
data streams, as communicated between partners in the interactive traffic management 
concept. Quality criteria are, for example, accuracy, latency and completeness. A negative 
example in terms of completeness is the SOCRATES? Road Works use case, where we 
experienced some inconsistent data coverage from the many data providers, making data 
fusion challenging. 


In the context of service quality, this concerns the performance of systems participating 

in the interactive traffic management concept. This relates to any role, as introduced in 
Section 2.2, including intermediaries. Considering that the entire use case depends on the 
proper functioning of every participating system, some agreements are needed for aspects 
such as the operational availability and robustness of the systems. 


In the context of quality levels, this often concerns minimum (or basic) levels required 
for a use case. Imagine, for example, a maximum latency for specific information to be 
transmitted to a road user. Ignoring that level may result in a road user rejecting the 
information, and thus making the entire system inefficient. 


Beyond the minimum levels, we also foresee some advanced levels with gradually 
improved qualities, based on the system's and partner's capabilities. Such an approach 
may enable a step-by-step deployment (starting with e.g. a minimum level and advancing 
from there), and also leave room for a quality-based competition between various partners 
in the concept (e.g. if there are multiple data providers operating in the same region). 





27 For example. Future projects under the call “Impact of CAD on Safe Smart Roads” by the CEDR Transnational Road Research 
Programme”, https://www.cedr.eu/news-data/1501/CEDR-Research-Call-2020-is-open! 
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Some definitions of similar quality criteria and quality levels have been elaborated within 
the EU EIP project? These contain some first agreements on data and service qualities for 
various ITS domains, based on stakeholder consultations and real-world data use cases. 
However, the EU EIP definitions are on more of a generic level, meaning they look at the 
RTTI domain as such, and do not detail quality levels for aspects such as individual data 
categories. Further, the EU EIP definitions look at the road operator's responsibilities, 
meaning they focus on data detection and provision on a NAP, and exclude subsequent 
data processes by private service providers. Data quality issues in the context of service 
providers were discussed by TISA”, but on a strategic level, without concrete level 
definitions. 


Within SOCRATES?*, we did in fact look at the quality aspects as part of the Evaluation 
activity. Here we found the encountered quality levels were considered sufficient or could 
be resolved within the pilot development. However, in other circumstances, for example 
without a setting of a limited project, there might be a clear need to pre-define such quality 
levels. This might be the case when selecting and assessing new partners in a deployment, 
based on a procurement procedure. 


Thus, we recommend further concretising (minimum) service and data qualities for 
future deployments of interactive traffic management. This may be a concrete definition 
and quantitative determination of quality levels for different quality criteria, separated 
for different data categories, different services and different use cases of interactive 
traffic management. Such definitions must, of course, reflect the requirements of any 
participating partner, and should be validated in real-world environments. 


A result might be a tabular determination as follows. Besides a definition of dedicated 
quality criteria, explicit requirements for each criterion should be laid down. Looking at the 
example about the Road Works use case above, such a definition might include a minimum 
requirement for data completeness, which needs to be ensured by each data provider 
before starting any deployment. 


Table 8. Example for a tabular determination of quality criteria 





Data latency 





Data accuracy 





Data completeness 





Service availability 





Service robustness 





etc. 


























28 See: https://www.its-platform.eu/achievement/quality-of-european-its-services-and-their-data 


5.5 Regulation & legislation 
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We have learned that many prereduisites for the interactive traffic management concept 
may be derived from stakeholder elaborations and pilot deployments, as demonstrated 

in SOCRATES?®. This is considered a bottom-up approach, which may be scaled up and 
streamlined in future deployments. In contrast, a top-down approach seems similarly 
important, to concretise necessary actions by the various partners in our concept, and 

to provide rules, support and perhaps incentives to accept such tasks. Next, we look at 
frameworks for regulation and legislation in the context of interactive traffic management. 


An important key player when setting such frameworks on the European level is the 
European Commission (EC), in particular DG MOVE. One major motivation for DG MOVE 
to fund the project was to spread out the project results on a wider scale, potentially 
across the European TEN-T network. As such, the follow-up discussion explored potential 
further triggers and prerequisites to advance the concept. During the project runtime, 
the SOCRATES2° management was in close contact with DG MOVE to exchange highlights 
and learnings and verify the alignment of the EC strategic considerations with our project 
approach. 


In parallel, DG MOVE elaborated new legislatures and frameworks that relate to our 
concept of interactive traffic management. 


One current EC regulatory measure is a planned revision of Delegated Regulation (EU) 
2015/962, a specification for EU-wide real-time traffic information services (RTTI)*°. First, the 
scope of this specification will be extended, by adding data categories, such as urban access 
regulations, and expanding the covered network elements, such as urban roads. The revision 
aims to facilitate transportation-related data access in urban settings, which so far has been 
a side topic in EC regulations. This kind of additional data should be provided at National 
Access Points, which according to Section 5.3 play an important role for data exchange in 
the SOCRATES?° Cooperation Framework. Second, the revision will sharpen some of the 
requirements to increase the efficiency and outreach of the Exchanged Data. One example 
is specified quality levels that the Exchanged Data should satisfy. Further, the role of service 
providers will be highlighted, being transmitters of traffic management information to 

road users. We expect this revision can serve as an accelerator for the interactive traffic 
management concept if appropriate and sufficient data offers are made available by the 
various data providers addressed in the regulation. This kind of data availability cannot be 
taken for granted. As such, certain technical and organisational prerequisites, especially in 
urban settings, need to be tackled first, as mentioned in Section 5.3. 





30 See the EC Working Programme for the ITS Directive. https://ec.europa.eu/transport/sites/transport/files/legislation/c20188264_ 
en.pdf 


84 


On a higher level, the EC has strategic frameworks that are also in line with our concept. 
First, the “Sustainable and Smart Mobility Strategy 20203 elaborates on the goals and 
actions for the clusters of sustainable, smart and resilient mobility, each with environmental 
and climate impacts in mind. Especially in the cluster of smart mobility, many topics can 

be linked to the SOCRATES?” concept. One of them is digitalisation, which aims to generate 
business opportunities, innovation, new services and business models. All these topics 
were central parts of the SOCRATES? elaboration. The other clusters were also targeted by 
SOCRATES?°, sometimes indirectly. For example, the sustainability aspect was addressed by 
the Copenhagen pilot, where one of the Network Manager's roles was to foster sustainable 
travel modes. We feel that SOCRATES22 paves the way to achieve some of these strategic 
goals as well. 


Furthermore, the “Data Strategy and the White Paper on Artificial Intelligence”? aims 
among other goals to create safer and cleaner transport systems via data-driven 
applications. Obviously, both data and applications play a central role in the SOCRATES?° 
concept, and applications may be assigned to our intermediary roles or the end-user 
services. This EC strategy aims to boost the data economy in Europe. This is also one of the 
SOCRATES?? goals, which we aim to achieve by elaborating new business opportunities for 
service providers, for example. On the other hand, we still consider the road authorities 
(without a primary economic focus) as crucial players in our concept, so we focused 

more on the aspects of cooperation. However, business aspects are also identified as an 
important follow-up action (see Section 5.3). 


Altogether, we realise that any deployments of interactive traffic management should 

be backed by strategic considerations, such as the ones mentioned above. This may 
incentivise further actions in terms of interactive traffic management. It may for example 
be a reasoning for responsible public authorities when deciding on future investments in 
traffic management schemes. 


5.6 Post-SOCRATES2° deployment 


Within the SOCRATES?° deployments, various components were developed that are 
considered mature enough to be used beyond the project. This relates to basic elaborations, 
as introduced in Section 2, but also concrete techniques from the pilot deployments. This 
legacy is important for future deployments, as some components can be reused or further 
advanced. This re-usage may generate momentum to implement the interactive traffic 
management concept on a wider scale. 





31 See the Fact Sheet on the EC Mobility Strategy. https://ec.europa.eu/transport/sites/transport/files/mobility-strategy-factsheet. 


32 See the Fact Sheet on the European Data Strategy. https://ec.europa.eu/commission/presscorner/api/files/attachment/862109/ 
European_data_strategy_en.pdf.pdf 
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Potential future deployments may also tackle some outstanding issues, as identified in 

the previous subsections. This relates, among other matters, to a further validation of 

the (more advanced) cooperation models Shared View and Coordinated Approach. It also 
relates to a full realisation of ‘integrated control loops’, a basic philosophy of the TM2.0 
concept (see section 2.1). More concretely, this implies that service providers need to fully 
integrate specific traffic management advice in their end-user systems, and that systematic 
feedback loops on the compliance of that advice are established to better measure impacts 
of the concept. Talking about impacts, more experiences are needed on the behavioural 
change of road users when applying these services. Due to limited evidence collected in 
SOCRATES2°, more empirics are needed to measure the outreach and effect of our concept 
on behaviour, possibly looking at different types and mobility demands of road users. 


Altogether, there is a clear need to catalyse future deployments, based on the SOCRATES?° 
concept, to validate and advance the current elaborations. In the following section, we look 
at concrete plans and activities of the SOCRATES?” partners, and, beyond that, at selected 
initiatives on regional, national and European levels. 


Regional and national initiatives 





On a regional and regional level, it is interesting to see how the SOCRATES?° concept is 
perceived locally, and whether there are any ambitions to use our elaborations in local 
deployments, or perhaps even to reframe our concepts to consider local conditions. There 
are many regional and regional initiatives underway aimed at advancing conventional traffic 
management schemes, thus touching on similar goals as in SOCRATES. These initiatives are 
coordinated outside the SOCRATES? project, either as a follow-up by SOCRATES?° project 
partners, or by external parties. Some examples are given in the next table. 


According to this table, there is a variety of follow-up initiatives across Europe, indicating 
that our concept and the first deployments are of high interest for stakeholders inside 
and outside the project. This means that there are ambitions to continue some of the 
SOCRATES?° deployments, based on the ambitions of some of the project partners to 
sustain the developed use cases even beyond the project timeline. 


There are also some external projects where our elaborations have been taken over as a 
template or a reference to establish similar concepts, possibly with some reframing and 
involving further stakeholders. One example of this is the German project City2Navigation, 
which is reusing some of SOCRATES?” concepts such as the cooperation framework, even 
though the project's scope is slightly different. In City2Navigation, the focus is on a wide 

scale, but low-tech effort, and thus enabling as many cities as possible to establish the lowest 
SOCRATES? cooperation model (data exchange), rather than having a few advanced solutions. 


Altogether, the many identified follow-up initiatives reveal that SOCRATES2.0 addresses an 
important field of actions among European ITS and traffic management stakeholders, and 
that these initiatives have the potential to deepen and validate our first steps for interactive 
traffic management. 
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Table 9. Examples for Regional and national initiatives 



































City2Navigation | BASt, TomTom, | Project aim: to establish | Finished in | https://www. 

Here a conceptual foundation | 2021 mdm-portal.de/ 
for exchanging forschungsprojekt- 
traffic management city2navigation/ 
information between 
urban TMCs in Germany 
and service providers. 

Mutual knowledge 

exchange with 

SOCRATES?® on 

cooperation models, 

intermediary roles, 

common data formats. 
Continuation Rijkswaterstaat, | Extend deployment until Dec Without prediction 
of SOCRATES*° MAPtm, due to pandemic, to 2021 
Optimising Technolution, enhance quality of 
Network Traffic Be-Mobile, evaluation data 
Flow use case in | Nationaal 
Amsterdam Dataportaal 

Wegverkeer 

Environmental Rijkswaterstaat, | Knowledge is ongoing Relation with 
Zone use casein | Nationaal contributed to ongoing UVARbox project 
the Netherlands | Dataportaal projects to share (see Section 5.6) 

Wegverkeer, environmental zone 

MAPtm, information (such as 

TomTom, UVARbox and VM-IVRA) 

Be-Mobile 

Continuation Flemish Deployment transferred | ongoing 

of SOCRATES?° government, into continuous 

Speed and Lane | Be-Mobile production 

Information use 

case in Antwerp 

Mobilidata Flemish Some use cases piloted | until 2023 | https://mobilidata. 

government in SOCRATES?° will be be/en/about- 

continued mobilidata 

Continuation Flemish Deployment transferred | ongoing Cooperation model 

of SOCRATES*° government, into continuous “Exchanged Data” 

Optimising Be-Mobile production applied 

Network Traffic 

Flow use case in 

Antwerp 

SOCRATES?2° Rijkswaterstaat | Series of 8 digital May 2021 In Dutch 

Masterclasses meetings explaining Novem- Open to everybody 
specific SOCRATES?° ber 2021 
learnings 








33 BAST = BASt; TTM = TomTom; HER = HERE; Rijkswaterstaat = Rijkswaterstaat; MAP = MAPtm; TEC = Technolution; BEM = Be- 
Mobile; Flemish government = Flemish government; Nationaal Dataportaal Wegverkeer = Nationaal Dataportaal Wegverkeer 
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Dutch Policy Rijkswaterstaat | Lessons learned serve Jan 2021- | Confidential 
Paper on as input for the internal | May 2021 
Public-Private discussion 
Cooperation 
SATURN project | BASt, TomTom Conceptualisation 2021-2023 | https://www.bmvi. 
and deployments for de/SharedDocs/DE/ 
dissemination of traffic Artikel/DG/mfund- 
management info to projekte/saturn. 
service providers via html 
the NAP, including four 
pilots in Germany 
Plateau Planning | Rijkswaterstaat | Lessons learned serve ongoing 
Rijkswaterstaat/ as input from testing 
Focus point to deployment to 
Smart Mobility production 
VM-IVRA (Traffic | Rijkswaterstaat, | sharing information ongoing 
Management Nationaal from the TMC scenarios 
Information For | Dataportaal and policy information, 
Route Advice) Wegverkeer SO service providers 
can inform road users 
even better. Using 
SOCRATES2.0 data 
formats and systems. 
SmartWayZ Rijkswaterstaat, | Discussion how 2021 https://www. 
regional MAPtm. to digitalise and smartwayz.nl/nl/ 
smart mobility Be-Mobile, disseminate policy rules actueel/2020/11/ 
program / “Slim | Nationaal from road authorities slim-sturen-in-zuid- 
sturen” pilot Dataportaal to traffic information nederland/ 
initiative Wegverkeer and navigation service https://www. 
providers. smartwayz.nl/en/ 
Amsterdam Rijkswaterstaat | The Amsterdam Practical | Summer https://www. 
Practical Trial Trial (APT) is a series of 2021 praktijk 
major pilot tests that use proefamsterdam. 
the latest innovations, nl/en 
both in cars and on the 
road. The APT tests new 
and improved services 
that integrate innovative 
systems on roads and in 
cars for road users. The 
objective is to improve 
traffic flow, make traffic 
safer and help make 
cities cleaner. 
TEMPUS BMW Lessons learned from 2021 - 
SOCRATES?! serve 2023 
as input for needed 
content of and ways of 
exchanging strategic 
information 
“Wakanda” Flemish Knowledge exchange ? 
initiative Belgium | government regarding the Road 








Works use case 
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Traffic, fleet MAPtm Application of yet to start | CEDR MANTRA 
and ODD cooperation framework 
management for 
highly automated 
vehicles, Helsinki 





RWS Tender for | Dutch Widespread yet to start 
Safety Priority Ministry of dissemination of 
Services Infrastructure safety-related events 
and Water or conditions on the 
management following topics: 
1) Traffic jam ahead 
warnings 


2) Emergency vehicles 
approaching 

3) Safety-related traffic 
information 

A) Traffic law 























Europe-wide 





Follow-up activities also relate to the European level. The goal here is to foster further 
harmonisation activities, to make the initial interactive traffic management concept more 
stable and sustainable across borders and responsibilities. There are several activities on 
the way, fostered either by stakeholder's organisations and by the European Commission. 
Three prominent activities are presented next. 


During the SOCRATES2.0 project, a close relationship was built with the TM2.0 ERTICO 
platform, e.g. by participating at a Special Interest Session about the Road Works use case, 
organised by TM2.0 at the Virtual ITS European congress in 2020. The session revealed 
several positive reactions and follow-ups about the SOCRATES? approach. Further, TM2.0 
initiated a new task force on the subject of the SOCRATES?° concept, including SOCRATES? 
partners Rijkswaterstaat, HERE, Be-Mobile, TomTom and Technolution. The objective is to 
disseminate the results of SOCRATES?! to the platform members, and provide context to 
the applicability of the results for other deployment initiatives. The outcome of this task 
force will be reported at the ITS congress 2021 in Hamburg. 


Anew, EU-funded project NAPCORE will start in the near future. It will be dedicated to the en- 
hancement and progress of NAPs*. As discussed in Section 5.3, NAPs are an important build- 
ing block for data cooperation between various partners in the transportation system. How- 
ever, even if many NAPs are already in operation across Europe, some issues and bottlenecks 
have been identified in terms of efficiency and the impact of individual NAPs. In particular, 
significant variations and heterogeneities in the status-quo of NAPs have been revealed in 
terms of aspects such as portal usability, applied data formats and the data coverage”. 





34An official inauguration and a web site for NAPCORE are planned for summer 2021. 
35 Hendriks, L., Jorna, R., Barr, J., Lubrich, P., Niculescu, M., Hjarp, L.O., Ilina, L., Gomes, R., Conceição, L., de Quirós, M. B., Rey, L. 
(2021). EU EIP - Annual NAP Report 2020, https://www.its-platform.eu/filedepot. download/1971/6703 
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To address these issues, NAP operators have teamed up as a stakeholder group, with the 
aim to support each other, exchange experiences and elaborate harmonised approaches 
when developing and operating NAPs. This group also proposed a concrete project 
NAPCORE, addressing a recent EC call for proposals with a focus on NAP federation?®®, 

This project will tackle harmonisation topics identified within this follow-up plan related to 
matters such as data standards (see Section 5.2) and data quality (see Section 5.3). Also, 
support actions will be initiated with the goal to enable and intensify data exchange in the 
domain of (urban) traffic management. We expect that such actions may accelerate future 
deployments of interactive traffic management. 


The time line of NAPCORE is set from mid-2021 until mid-2024. Former SOCRATES2° 
partners Rijkswaterstaat, BAST and the Flemish road agency AWV will participate in this 
project. 


Another ongoing EU-funded project is UVARbox, with the goal of digitising data about 
urban vehicle access regulations (UVAR) across Europe”. One of the expected results is 
a pilot setting with five pilot member states: the Netherlands, Belgium, Germany, Austria 
and Italy, and a focus on low emission zones. Digital information about individual UVAR 
will be formatted via DATEX II, thus building on the DATEX II profile, as elaborated for the 
SOCRATES?° Environmental Zone use case (see Section 2.3). 


The timeline of UVARbox is from 2020 until 2022. Former SOCRATES?” partners MAPtm is 
participating in this project. 


Altogether, such European activities contribute to a wider acceptance and maturity of 
the interactive traffic management concept. As stated throughout the report, important 
cornerstones of the interactive traffic management concept need to be agreed upon 
among various stakeholders and across geographical boundaries. Consequently, any 
European activities are appreciated which continue with the exploration of the interactive 
traffic management concept, either as a whole, or looking at some elements of it. 


For the future, we recommend identifying further funding and deployment opportunities 
with a European focus. An option might be to adapt and enhance the SOCRATES?° 

use cases in other European cities and regions, or to elaborate new use cases with 
interoperability features, for example with cross-border traffic management schemes. 
This way, the foundations from SOCRATES?” could be further integrated across Europe. 





36 Programme Support Action under the CEF Transport related to MOVE/B4/2020-123 - the implementation of a 
Coordination mechanism to federate the National Access Points established under the ITS Directive (2010/40/EU) 
37 See: https://uvarbox.eu/about/ 
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ANNEX I: Glossary 


Assessor: A SOCRATES?” intermediary role, in charge for 
providing insights on the service performance of 
partners involved in the delivery of the service 
(see Section 2.2) 


Business model: A further elaboration of the cooperation 
framework with the goal to create a common 
value proposition (see Section 5.3) 


Cooperation framework: A basic building block for the concept of 
interactive traffic management (see Section 2.2) 


Cooperation model: A model describing the type and intensity of 
cooperative tasks among the participating 
partners (see Section 2.2) 


Data provider: A public or private partner responsible for the 
delivery of data (see Section 2.2) 


DATEX II: An electronic language used in Europe for the 
exchange of traffic information and traffic data 
(see Section 2.3) 


DVM Exchange: Dutch data exchange format between TMCs in 
order to request services (see Section 2.2) 


Environmental Zone (EZ): A use case in the SOCRATES2° deployments (see 
Annex Il and the pilot site reports) 


Interactive traffic management: The basic SOCRATES?” concept integrating road 
authorities and service providers (see Section 2.1) 


Intermediary: A dedicated role between the traditional public 
and private sector, enables central functions of 
the interactive traffic management concept (see 
Section 2.2) 


Network Manager: A SOCRATES?” intermediary role, in charge for 
determination of the problem state, service 
selection and service requests (See Section 2.2) 


Network Monitor: A SOCRATES?” intermediary role, in charge for 


data collection and determination of the shared 
view (see Section 2.2) 
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Optimised Network Traffic Flow (ONTF): A use case in the SOCRATES2.0 deployments (see 


Service request: 


Smart Destination (SD): 


SP Service Provider (SP): 


Strategy Table: 


TMex: 


Traffic Management Centre (TMC): 


Annex Il and the pilot site reports) 


The process of requesting another partner 
to conduct a particular service via an agreed 
exchange format (see Section 2.2) 


A use case in the SOCRATES2.0 deployments (see 
Annex Il and the pilot site reports) 


A public or private partner in charge for receiving, 
assessing and distributing service requests to 
individual service users (see Section 2.2) 


A SOCRATES2.0 intermediary role, in charge of 
developing the joint strategy of all participating 
parties (see Section 2.2) 


A conceptual architecture for the exchange 
of traffic management data between the 


SOCRATES2.0 partners (see Section 2.3) 


An operational organisation of the road authority 
for traffic management 
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ANNEX Il: SOCRATES?” project history and set-up 


To develop and demonstrate the above-mentioned concept, six road authorities from four 
countries, five international traffic information and service providers, one car manufacturer 
and two companies for Intelligent Transport Systems (ITS) agreed to cooperate ina 
common project called SOCRATES2° 


IN July 2017, the European Commission decided to support and co-fund the project under 
Grant Agreement No INEA/CEF/TRAN/M2016/1366032 under the Connecting Europe Facility 
(CEF) programme. 


In 2017 and 2018, the project partners developed new services for traffic management 
and traffic information. In 2019 and 2020, they deployed and tested these new services. 
The testing was done with a test fleet of more than 10.000 road users in the regions of 
Amsterdam, Antwerp, Copenhagen and Munich. In 2021, evaluation and consolidation 
activities looked back at the project outcomes, and defined follow-up activities. 


The project is divided into nine activities. Besides a management activity (Act. 1), there were 
eight activities to develop, demonstrate and reflect the SOCRATES? concept, following a 

“yv approach”, see figure below. They start at a strategical level (Act. 2), proceed via a tactical 
level (Act. 3) to an operational level (Act. 4-7) , and from there back again to tactical (Act. 8) 
and strategical levels (Act. 9). 


CEF call on ITS Public policies and business strategies 


Activity 1: Project management 


Activity 2: Integrated traffic Sa ae, ee 
management framework Activity 9: Consolidation 


Activity 3: Common designs Activity 8: Evaluation 
and specification i 


Activity 4, 5, 6 and 7: Pilots in the regions of 
Amsterdam - Copenhagen - Munich - Antwerp 





FAST SAFE GREEN SOCRATES2° 


Figure A1. SOCRATES? project set-up 
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In Activity 2, all partners were involved in setting up the SOCRATES? vision as the basis for 
the further work in the other activities, making sure to create a mutual understanding of 
the objectives, context and terminology and establish a successful collaboration between 
partners based on trust and common goals. This vision is explained in Section 2.1. To fulfil 
such vison, various steps were undertaken to concretise the project approach. Since the 
road user is a central element in the vision, potential use cases were illustrated. These 
include a list of steps defining the interactions between actors and systems to achieve 

the goals. Then, it was assessed how the stakeholders can cooperate to be able to take 
these steps. And finally, the concept of the cooperation models and corresponding 
intermediaries is explored, to enable the elaborated use cases. The cooperation model and 
intermediary concept is explained is Section 2.3. 


Activity 3 prepared the pilot deployments of the interactive traffic management concept, by 
predefining and agreeing on certain cornerstones and building blocks, thus working towards 
consistency across each pilot setting. Major work was done by concretising the uses cases to 
be deployed by each participating city, as well as cooperation models (as initiated in Activity 
2) and the corresponding Intermediaries. The selected uses cases included: 


e Optimising Network Traffic Flow (ONTF) 
e Smart Destination (SD) 

e Speed and Lane Information (SLI) 

e Road Works (RW) 

e Environmental Zones (EZ) 


Eventually, a matrix was built combining the selected use cases, pilot cities and cooperation 
models as follows. It is evident that there was a good spread of use cases and cooperation 
models, promoting a “big picture” in terms of learnings and outcomes. 


Table A1. SOCRATES*° matrix with selected use cases, pilot cities and cooperation models 


Pilot Site Pilot Site Pilot Site Mun Pilot Site 
Amsterdam Copenhagen Antwerp 


Optimising 
Network Traffic 
Flow 


Smart 
Destination 


Environmental 
Zone 





95 


Further definitions and agreements were made about data exchange mechanisms, called 
the TMex approach. Here, data availabilities and requirements per pilot site, use case and 
partner were inventoried and concretised. For certain data exchange aspects, uniform 
solutions were elaborated, namely harmonized DATEXII profiles, with the recommendation 
to be used across the different pilot sites. This approach is contributing to the envisioned 
scalability and transferability of the SOCRATES?® concept. 


Activities 4, 5, 6, 7 were about demonstrating the concept by operating the cooperation 
framework in four different European Cities using five different use cases. A main goal was 
to test and showcase the viability, scalability, applicability and cost-effectiveness of the 
elaborated concepts. The approach in each pilot city was organised into four stages: 





e Stage 1: Specifications & Interface descriptions 

e Stage 2: Development, Implementation & Testing, approval of recruitment plans and 
evaluation data collection plans 

e Stage 3: Execution & Operation 

e Stage 4: Restoring & Settlement 


The pilot deployments had the following characteristics: 


e Activity 4, Pilot Amsterdam, operations between December 2019 and December 2020 
e Activity 5, Pilot Copenhagen, operations between April 2020 and December 2020 

e Activity 6, Pilot Munich, operations between since December 2019 and December 2020 
e Activity 7, Pilot Antwerp, operations between October 2019 and December 2020 


In Activity 8, Evaluation, different resources were exploited, in order to find conclusions for 
predefined evaluation questions. To do so, relevant data about the four pilot sites were 
collected and stored. Other resources were logbooks, questionnaires and interviews. 


The data-driven evaluation approach represents another innovation in the SOCRATES?° 
approach: a database and a data dashboard were developed and deployed, making 

it possible to monitor and assess the collection of the evaluation data throughout the 
deployment period. To feed this evaluation database, several data exchange connections 
were set up with the deployment partners in the different pilot cities. Thus, a sophisticated 
data ecosystem to simultaneously monitor various pilot settings was established, allowing 
high efficiency and comparability for the generation of evaluation results. 


Overall, the evaluation took place on 4 levels, as shown the following figure: 
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SOCRATES?’ goals LEVEL 1 Evaluation of scalability 


Evaluation based on the four SOCRATES?’ elements: 
Customer, Community, Technology and Cooperation 


Four SOCRATES?” elements LEVEL 2 


Cross pilot LEVEL 3 A comparative analysis at cross-pilot level 


Use case LEVEL 4 Data collection and depth analysis at the single use case/pilot site level 


Technical 
technical conduct and 
data management 
and quality 


Organisational Functional 
cooperative user acceptance and 
(public/private) traffic effectiveness 





FAST SAFE GREEN SOCRATES2° 


Figure A2. SOCRATES* evaluation set-up 
As pilot-specific evaluations on level 4, the evaluation perspective was on: 


e Technical performance: focusing on quality, reliability etc. of the developed systems 
and services 

e Functional performance: focusing on the impact the services, e.g. by considering the 
number of the amount of reached users 

e Organisational performance: focusing on the way the partners cooperate, related to the 
developed cooperation framework 


The outcomes of the evaluation activities are reported in D8: SOCRATES2.0 Evaluation. 
Activity 9, which main result is this Consolidation Report, wraps up the entire project, 


in terms of the validation of the SOCRATES?” concept, and compiling future actions as a 
follow-up plan. 


97 


ANNEX III: Pilot site elaborations and inventory 





As the pilot sites evolved mostly independently, we made some efforts to identify all pilot 
site-related results in a comprehensive manner. To do so, a “Content List” was created for 
each pilot site, being an inventory of all elaborations divided into six main types: Software 
applications, Algorithms, Standards, Documents, Software Interfaces and Data Feeds. 


The goal of such “Content List” is (a) to have an overview on pilot site-related contents/ 
elaborations and (b) to determine dissemination activities regarding relevant contents. 
Such dissemination was eventually a major input for this Consolidation Report. For a 
generic impression, only the Content List for Amsterdam consists of more than 50 items. 


Comparing all Content Lists, there seem be repeating, basic components for the six 
mentioned types throughout many pilot sites. These are summarised in the next figure, 
which may be considered a “construction kit” for a typical set-up of a pilot deployment. 


Pilot set-up 


Software Software 


se Algorithms Standards Documents À Data feeds 
applications interfaces 


Harmonisation Data exchange 


Web viewer z $ 
of services format 


Role description API endpoint Traffic state 


Impact KPI framework Road work 


End user App calculation i b information 


Conflict Active TM 


Reward system 


resolving measures 


Recruitment 
plan 


Functional 
design 





FAST SAFE GREEN SOCRATES2° 


Figure A3. Basic components of a pilot deployment 


It can be concluded that that a typical pilot deployment involves some basic components, 
which are necessary to establish the interactive traffic management concept as such. 
Whenever applied across multiple pilot sites and/or use cases, such basic elaborations 
should be harmonised, where possible. This was done in SOCRATES?” via, e.g. a common 
data exchange format, see Section 2. Other elaborations, on the other hand, are specific 
from pilot to pilot, due do different set-ups and use cases. 


The individual “Content Tables” for the four pilot sites are presented on the next pages. 
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Table A2. SOCRATES? content table for the Amsterdam pilot site 









































additional functionality and 
HMI's of BrandMKRS 














ONTF Description of the role document all Fact Sheet about Strategy 
Strategy Table Amsterdam Table, Pilot Site Report 
Amsterdam 
ONTF Strategy Table KPI document all Fact Sheet about Strategy 
framework Table, Pilot Site Report 
Amsterdam 
ONTF Description of the role document all Fact Sheet about Network 
Network Monitor Amsterdam Monitor, Pilot Site Report 
Amsterdam 
ONTF Description of the role document all Fact Sheet about Network 
Network Manager Amsterdam Manager, Pilot Site Report 
Amsterdam 
ONTF Description of the role document all Fact Sheet about 
Assessor Amsterdam Assessor, Pilot Site Report 
Amsterdam 
ONTF Tilted table specification | document Nationaal Fact Sheet about Network 
Dataportaal Monitor, Pilot Site Report 
Wegverkeer Amsterdam 
Protocol for a Reward system document Be-Mobile/MAPtm | Fact Sheet about 
Rewarding System, Pilot 
Site Report Amsterdam 
End User Service Be-Mobile software Be-Mobile Fact Sheet about End-user 
application Services Be-Mobile, Pilot 
Site Report Amsterdam 
End User Service BMW software BMW Fact Sheet about End-user 
application Services BMW, Pilot Site 
Report Amsterdam 
End User Service TomTom software TomTom Pilot Site Report 
application Amsterdam 
End User Service BrandMKRS software BMK Fact Sheet about End-user 
application Services BrandMKRS, Pilot 
Site Report Amsterdam 
Development of new or software Be-Mobile Fact Sheet about End-user 
additional functionality and Services Be-Mobile, Pilot 
HMIS of Be-Mobile Site Report Amsterdam 
Development of new or software BMW Fact Sheet about End-user 
additional functionality and Services BMW, Pilot Site 
HMIS of BMW Report Amsterdam 
Development of new or software TomTom Pilot Site Report 
additional functionality and Amsterdam 
HMI's of TomTom 
Development of new or software BMK Fact Sheet about End-user 


Services BrandMKRS, Pilot 
Site Report Amsterdam 
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ONTF DVM Exchange Active data feed Nationaal Fact Sheet about Network 
Traffic Measures from Road Dataportaal Manager, Pilot Site Report 
Authorities to Tilted table Wegverkeer + RAS | Amsterdam 
data exchange (MobiMaestro 
RA's - Nationaal Dataportaal 
Wegverkeer) 
ONTF Tilted table data data feed Nationaal Fact Sheet about Network 
exchange from Network Dataportaal Monitor, Pilot Site Report 
Monitor to Network Manager Wegverkeer Amsterdam 
ONTF Data feed predicted data feed TomTom Fact Sheet about Network 
state data delivery TomTom Monitor, Pilot Site Report 
Amsterdam 
ONTF Data feed predicted data feed Be-Mobile Fact Sheet about Network 
state data delivery Be-Mobile Monitor, Pilot Site Report 
Amsterdam 
ONTF Predicted traffic state data feed Nationaal Fact Sheet about Network 
data delivery Nationaal Dataportaal Monitor, Pilot Site Report 
Dataportaal Wegverkeer/PTV Wegverkeer / PTV Amsterdam 
ONTF MobiMaestro web software Technolution Fact Sheet about Network 
viewer application Manager, Pilot Site Report 
Amsterdam 
ONTF MobiMaestro application | software Technolution/ Fact Sheet about Network 
application Rijkswaterstaat Manager, Pilot Site Report 
Amsterdam 
ONTF Toolbox -set of services document Technolution/ Fact Sheet about Network 
Rijkswaterstaat Manager, Pilot Site Report 
Amsterdam 
ONTF Predicted problem state | document Technolution/ Fact Sheet about Network 
definition Network Manager Rijkswaterstaat Manager, Pilot Site Report 
Amsterdam 
ONTF Harmonisation algorithm Technolution/ Fact Sheet about Network 
of services, impact Rijkswaterstaat Manager, Pilot Site Report 
calculation and conflict Amsterdam 
resolving (Technolution / 
Rijkswaterstaat) 
ONTF AVOID Service Request data feed Technolution/ Fact Sheet about DATEX 
(part of TMEx) Rijkswaterstaat IL, Pilot Site Report 
Amsterdam 
ONTF AVOID Route Service data feed Technolution/ Fact Sheet about DATEX 
Request (part of TMEx) Rijkswaterstaat II, Pilot Site Report 
Amsterdam 
ONTF REROUTE Service data feed Technolution/ Fact Sheet about DATEX 
Request (part of TMEx) Rijkswaterstaat II, Pilot Site Report 
Amsterdam 
SD and ONTF REROUTE Service | data feed Rijkswaterstaat Fact Sheet about DATEX 
Request (part of TMEx) IL, Pilot Site Report 
Amsterdam 
Recruitment plan Be-Mobile document Be-Mobile Pilot Site Report 











Amsterdam 
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Recruitment plan BrandMKRS | document BMK Pilot Site Report 
Amsterdam 
Recruitment plan BMW document BMW Pilot Site Report 
Amsterdam 
Recruitment plan TomTom document TomTom Pilot Site Report 
Amsterdam 
SD Data exchange format data feed Nationaal Fact Sheet about DATEX 
(DATEX II): road closures Dataportaal IL, Pilot Site Report 
Wegverkeer Amsterdam 
SD DVM Exchange parking data feed Technolution * Pilot Site Report 
guidance to DATEX Il service Amsterdam Amsterdam 
request (MobiMaestro 
Amsterdam- Technolution) 
EZ Data exchange format / data feed Nationaal Fact Sheet about DATEX 
DATEX Il - RAZ Dataportaal IL, Pilot Site Report 
Wegverkeer Amsterdam 
ONTF “Intekentool VM-IVRA”: application Nationaal Fact Sheet about Network 
tool for TMC's and RA's to Dataportaal Monitor, Pilot Site Report 
register traffic management Wegverkeer Amsterdam 
measures 
EZ API endpoint: software Nationaal Pilot Site Report 
environmental zone (EZ) interface Dataportaal Amsterdam 
Wegverkeer 
SD API endpoint: road closures | software Nationaal Pilot Site Report 
interface Dataportaal Amsterdam 
Wegverkeer 
SD API endpoint: service software Technolution Pilot Site Report 
requests parking and reroute interface Amsterdam 
Recruitment Dashboard document all Pilot Site Report 
Amsterdam 
EZ: DVM Exchange dynamic data feed Nationaal Fact Sheet about DATEX 
EZ from Amsterdam to DATEX Dataportaal II, Pilot Site Report 
Il - RAZ dynamic and static Wegverkeer + Amsterdam 
message EZ Amsterdam 
Functional design of service document Be-Mobile Fact Sheet about End-user 
per use case Be-Mobile Services Be-Mobile, Pilot 
Site Report Amsterdam 
Functional design of service document BMK Fact Sheet about End-user 
per use case BrandMKRS Services BrandMKRS, Pilot 
Site Report Amsterdam 
Functional design of service document BMW Fact Sheet about End-user 
per use case BMW Services BMW, Pilot Site 
Report Amsterdam 
Functional design of service document TomTom Pilot Site Report 


per use case TomTom 
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Amsterdam 


























ONTF: map matching from algorithm Nationaal Pilot Site Report 

Data Provider network Dataportaal Amsterdam 

segments to Nationaal Wegverkeer 

Dataportaal Wegverkeer 

segments 

ONTF: Waterfall method for document MAPtm Fact Sheet about 

reporting impact Assessor, Pilot Site Report 
Amsterdam 

ONTF: Waterfall method for software MAPtm Fact Sheet about 

reporting impact application Assessor, Pilot Site Report 
Amsterdam 

RW: Improved Road Works data feed MAPtm Pilot Site Report 

information feed Amsterdam 

Road Works: Socrates service document MAPtm Fact Sheet about DATEX 

Data feed specifications: JSon / II, Pilot Site Report 

XML message Amsterdam 

SD DVM Exchange Road data feed Nationaal Fact Sheet about DATEX 

Closures Amsterdam to DATEX Dataportaal IL, Pilot Site Report 

Il Road Closures Nationaal Wegverkeer + Amsterdam 

Dataportaal Wegverkeer Amsterdam 

(MobiMaestro Amsterdam 

- Nationaal Dataportaal 

Wegverkeer) 

Template Network Manager document Rijkswaterstaat Fact Sheet about Network 

and Toolbox (Excel sheet) Manager, Pilot Site Report 
Amsterdam 
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Table A3. SOCRATES?? content table for the Antwerp pilot site 





















































ONTF/ CM4 Description of document all Fact Sheet about Network 
the role Network Manager Manager, Pilot Site Report 
Antwerp Antwerp 
End User Service Be-Mobile software Be-Mobile Fact Sheet about End-user 
application Services Be-Mobile, Pilot 
Site Report Antwerp 
End User Service BMW software BMW Fact Sheet about End-user 
application Services BMW, Pilot Site 
Report Antwerp 
Development of new or software Be-Mobile Fact Sheet about End-user 
additional functionality and Services Be-Mobile, Pilot 
HMIs of Be-Mobile Site Report Antwerp 
Development of new or software BMW Fact Sheet about End-user 
additional functionality and Services BMW, Pilot Site 
HMIS of BMW Report Antwerp 
ONTF / CM4 current traffic data feed AWV Fact Sheet about Network 
state data delivery AWV Monitor, Pilot Site Report 
Antwerp 
ONTF / CM4 Network Manager | software MAPtm Fact Sheet about Network 
web viewer application Manager, Pilot Site Report 
Antwerp 
ONTF / CM4 Current state / software MAPtm Fact Sheet about Network 
Problem state algorithm application Manager, Pilot Site Report 
Antwerp 
ONTF / CM4 Problem state document AWV / MAPtm Fact Sheet about Network 
definition Network Manager Manager, Pilot Site Report 
(thresholds) Antwerp 
ONTF / CM1 / CM4 API end data feed MAPtm Fact Sheet about DATEX II, 
point Pilot Site Report Antwerp 
CM1 and CM4 API data feed MAPtm Fact Sheet about DATEX II, 
Pilot Site Report Antwerp 
Functional design of service document Be-Mobile Fact Sheet about End-user 
per use case Be-Mobile Services Be-Mobile, Pilot 
Site Report Antwerp 
Functional design of service document BMK Fact Sheet about End-user 
per use case BrandMKRS Services BrandMKRS, Pilot 
Site Report Antwerp 
Functional design of service document BMW Fact Sheet about End-user 
per use case BMW Services BMW, Pilot Site 
Report Antwerp 
ONTF / CM1 Measures data feed AWV Fact Sheet about Network 
Manager, Pilot Site Report 
Antwerp 
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ONTF/ CM4 Waterfall method document MAPtm Fact Sheet about Assessor, 
for reporting impact Pilot Site Report Antwerp 
RW: Improved Road Works data feed MAPtm Fact Sheet about DATEX II, 
information feed Pilot Site Report Antwerp 
RW: Socrates service Data document MAPtm Fact Sheet about DATEX II, 
feed specifications: JSon / XML Pilot Site Report Antwerp 
message 
RW: Network Monitor software MAPtm Fact Sheet about DATEX Il, 
ingestion and fusion system Pilot Site Report Antwerp 
RW: digestion of Road Works software MAPtm Fact Sheet about DATEX II, 
by SP's (public and private) Pilot Site Report Antwerp 
SLA current lane control data feed AWV Fact Sheet about Network 
signing data delivery AWV Monitor, Pilot Site Report 
Antwerp 
ONTF/ CM4 voucher system document all Fact Sheet about Voucher 
description System Antwerp, Pilot Site 
Report Antwerp 
ONTF/ CM4 voucher document all Fact Sheet about Voucher 
system contract nv Tunnel System Antwerp, Pilot Site 
Liefkenshoek Report Antwerp 
ONTF/ CM4 voucher system document Liefkenshoek Fact Sheet about Voucher 
toll collector instructions System Antwerp, Pilot Site 
Report Antwerp 
ONTF/ CM4 description of document all Fact Sheet about Voucher 
system setup leading to win- System Antwerp, Pilot Site 
win-win Report Antwerp 
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Table A4. SOCRATES? content table for the Munich pilot site 



































Route Strategies Munich Fair + | document Bavarian Pilot Site Report Munich 

Allianz arena (VMS contents + Motorway 

georeference via OpenLR) Administration 

Route IDs Munich Fair, document Bavarian Pilot Site Report Munich 

including route description Motorway 

and reason (Lookup-table) Administration 

DATEX Il representation of data feed Bavarian Fact Sheet about DATEX II, 

route recommendations to Motorway Pilot Site Report Munich 

Munich Fair (“StrategicRouting. Administration 

xsd") 

DATEXII publication data feed Bavarian Fact Sheet about DATEX II, 

“Strategisches Routing WWW” Motorway Pilot Site Report Munich 

on the MDM Administration 

BMW internal back-end, software BMW Fact Sheet about End-user 

including geofenced service application Services BMW, Pilot Site 

dissemination to end users Report Munich 

BMW end-user service software BMW Fact Sheet about End-user 

(“Managed City Drive”) application Services BMW, Pilot Site 
Report Munich 

RW: Improved Road Works data feed MAPtm Fact Sheet about DATEX II, 

information feed Pilot Site Report Munich 

RW: Socrates service Data document MAPtm Fact Sheet about DATEX II, 

feed specifications: JSon / XML Pilot Site Report Munich 

message 

RW: Network Monitor software MAPtm Fact Sheet about DATEX II, 

ingestion and fusion system Pilot Site Report Munich 

RW: digestion of Road Works software MAPtm Fact Sheet about DATEX II, 


by SP's (public and private) 











Pilot Site Report Munich 
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Table A5. SOCRATES? content table for the Copenhagen pilot site 


















































EZ Data exchange format data feed TNL Fact Sheet about DATEX 

/ DATEX Il (area instead of IL, Pilot Site Report 

stretch of road) Copenhagen 

End User Service TomTom software TomTom Pilot Site Report 

application Copenhagen 
End User Service BrandMKRS software BMK Fact Sheet about End-user 
application Services BrandMKRS, Pilot 

Site Report Copenhagen 

Development of new or software TomTom Pilot Site Report 

additional functionality and Copenhagen 

HMIS of TomTom (considering 

environmental zone & cyclist 

information) 

Development of new or software BMK Fact Sheet about End-user 

additional functionality Services BrandMKRS, Pilot 

and HM's of BrandMKRS Site Report Copenhagen 

(messages which are time- 

based dependent of event) 

Recruitment plan BrandMKRS | document BMK Pilot Site Report 
Copenhagen 

Recruitment plan TomTom document TomTom Pilot Site Report 
Copenhagen 

Recruitment Dashboard document all Pilot Site Report 
Copenhagen 

Functional design of service document BMK Fact Sheet about End-user 

per use case BrandMKRS Services BrandMKRS, Pilot 
Site Report Copenhagen 

Functional design of service document TomTom Pilot Site Report 

per use case TomTom Copenhagen 

ONTF Description of the role document all Fact Sheet about Network 

Network Monitor Copenhagen Monitor, Pilot Site Report 
Copenhagen 

Gathering data from air quality | software Technolution Fact Sheet about Network 

sensors for Network Monitor Monitor, Pilot Site Report 
Copenhagen 

Gathering data from cycling software Technolution Fact Sheet about Network 

sensors for Network Monitor Monitor, Pilot Site Report 
Copenhagen 

ONTF Description of the document all Fact Sheet about Network 

role Network Manager Manager, Pilot Site Report 

Copenhagen, multimodal Copenhagen 

approach 
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ONTF Data feed current state 
data delivery TomTom 


data feed 


TomTom 


Pilot Site Report 
Copenhagen 














SD MobiMaestro application software Technolution Fact Sheet about Network 
application Manager, Pilot Site Report 

Copenhagen 

ONTF Toolbox -set of services document Technolution Fact Sheet about Strategy 
Table, Pilot Site Report 
Copenhagen 

ONTF Harmonisation of algorithm Technolution Fact Sheet about Network 

services, impact calculation Manager, Pilot Site Report 

and conflict resolving, incl. Copenhagen 

cyclists data to send an avoid 

ONTF AVOID Service Request data feed Technolution/ Fact Sheet about DATEX 

(part of TMEx) Rijkswaterstaat IL, Pilot Site Report 
Copenhagen 

Log of Network Manager and document Technolution Fact Sheet about Network 


Toolbox (Excel sheet) 











Manager, Pilot Site Report 
Copenhagen 
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